Could you spare a few words on what exactly "thread-safe" means?

In the most simple sense, it just means safely usable from mutiple threads. For a more expansive, but generic definition, I cannot do better than wikipedia.

For an answer specific to the use of this particular module, it probably(*) means that it would be safe to use OpenGL in a threaded Perl app, provided that you only call OpenGL from one thread. (This should be safe in as much as every app is a "threaded app", just some of them only use one thread.)

The error message you posted comes about because although you have made no reference to OpenGL within the thread you spawned, threads is trying to clone everything that exists within your main thread at the point of thread creation, into that new thread. As you have use OpenGL;, which is acted upon at BEGIN-time, by the time you create your thread, it already contains stuff from OpenGL. And when threads tried to clone it, for some reason it cannot find the class/module GLUquadricObjPtr.

In theory, you could avoid that problem by delaying the loading of OpenGL until after you created your thread. Something like:

#! perl -slw
use strict;
use threads;

async{ print 'from thread' }->detach;

require OpenGL;
OpenGL->import( ':all' );
...
[download]

But require followed by import isn't exactly the same as use, in as much as the timing is different. Put it in a BEGIN() block and it is imported prior to your creating the thread, and it gets cloned. Put it in-line with the body of your code, as above, and some or all of the imports are not available (at the appropriate time?) and you get:

c:\test>GLex7.2.pl
Bareword "GL_FRONT" not allowed while "strict subs" in use at c:\test\
+GLex7.2.pl line 15.
Bareword "GL_AMBIENT" not allowed while "strict subs" in use at c:\tes
+t\GLex7.2.pl line 15.
Bareword "GL_FRONT" not allowed while "strict subs" in use at c:\test\
+GLex7.2.pl line 16.
Bareword "GL_SPECULAR" not allowed while "strict subs" in use at c:\te
+st\GLex7.2.pl line 16.
Bareword "GL_FRONT" not allowed while "strict subs" in use at c:\test\
+GLex7.2.pl line 17.
Bareword "GL_SHININESS" not allowed while "strict subs" in use at c:\t
+est\GLex7.2.pl line 17.
Bareword "GL_LIGHTING" not allowed while "strict subs" in use at c:\te
+st\GLex7.2.pl line 19.
Bareword "GL_LIGHT0" not allowed while "strict subs" in use at c:\test
+\GLex7.2.pl line 20.
Bareword "GL_LEQUAL" not allowed while "strict subs" in use at c:\test
+\GLex7.2.pl line 21.
Bareword "GL_DEPTH_TEST" not allowed while "strict subs" in use at c:\
+test\GLex7.2.pl line 22.
Bareword "GL_FALSE" not allowed while "strict subs" in use at c:\test\
+GLex7.2.pl line 25.
Bareword "GLUT_DOUBLE" not allowed while "strict subs" in use at c:\te
+st\GLex7.2.pl line 84.
Bareword "GLUT_RGBA" not allowed while "strict subs" in use at c:\test
+\GLex7.2.pl line 84.
Bareword "GLUT_DEPTH" not allowed while "strict subs" in use at c:\tes
+t\GLex7.2.pl line 84.
Execution of c:\test\GLex7.2.pl aborted due to compilation errors.
[download]

Try to bypass that by disabling strict and you get:

c:\test>GLex7.2.pl
from thread
Argument "GLUT_VOWWLE" isn't numeric in subroutine entry at c:\test\GL
+ex7.2.pl line 84.
Argument "GL_FRONT" isn't numeric in subroutine entry at c:\test\GLex7
+.2.pl line 15.
Argument "GL_AMBIENT" isn't numeric in subroutine entry at c:\test\GLe
+x7.2.pl line 15.
Unknown material parameter at c:\test\GLex7.2.pl line 15.
[download]

Which means that still some of the imports you get from use OpenGL qw[ :all ]; and not available when you do require OpenGL; OpenGL->import( ':all' );. That's pretty frustrating of itself, but the real problem is there is no way to create a thread without it doing the cloning. Now that is really frustrating.

If I ever work out how to do that I'll publish the mechanism, and then many of these pissant frustrations will go away. (Update:rant deleted)

(*)Bottom line: You can probably get away with mixing OpenGL and threads provided:

• you only call OpenGL from one thread.

  I've also tried sticking my entire app into a thread and having the main thread just print heartbeat messages one a second and that worked fine too, though it isn't the most complex of OpenGL apps.

• you can live with getting that warning each time you create a thread.

  Not great, but the best I can offer at the moment.

Wow. Thanks a lot, i learned a good bit about threads from this and have managed to launch the thread in a manner that eradicates the error message and probably makes the thread a lot happier by not encumbering it with the OpenGL stuff unnecessarily:
Read more... (1403 Bytes)

I wasn't planning to actually use OpenGL threaded anyhow, but actually only wanted to offload blocking operations that can work in the background.

One thing i stumbled across though: Do you think it would be possible to safely create a thread that binds the glut keyboard input callbacks and then creates a second opengl main loop that processes ONLY those? Alternatively, is there a way to do event systems directly within perl or while loops that can react quickly, but don't use up 100% CPU?

In a similar vein: If i would, say, declare $sleep_time above outside the thread, then modify it in the main program, would the changes be noticed by the thread or would it need to be shared first?

Hmm. About all I can say is that you are moving in uncharted waters. threads used to carry a dire warning about creating threads inside special blocks:

Creating threads inside BEGIN, CHECK or INIT blocks should not be relied upon. Depending on the Perl version and the application code, results may range from success, to (apparently harmless) warnings of leaked scalar, or all the way up to crashing of the Perl interpreter.

And, unlike some of the other overly pessimistic warnings about threads, I've personally experienced intermittant failures and traps when using threads created within BEGIN{} blocks. From memory, these occured with both 5.8.3 and 5.8.5, hence I gave up trying long ago. I don't have a handle on how things stand on later builds.

That warning has now disappeared from the latest cpan version of threads, but there's no real way to know if it was deliberately removed because the cause had been found and fixed, or if it just got omitted along the way.

Do you think it would be possible to safely create a thread that binds the glut keyboard input callbacks and then creates a second opengl main loop that processes ONLY those?

The whole area of callbacks and threads is pretty iffy. Even conceptually. What happens if the code doing the calling back is running in a different thread to that which passed in the address to be called back?

At the C-level, provided that the callback routine is reentrant and doesn't rely on thread local storage, it'll probably work ok. But in Perl, I really have no idea what would happen, but my gut feeling is that it wouldn't be good.

And the idea of running two "main loops" seems very unlikely to work.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

I would keep all things related to OpenGL within one thread, and preferrably the main thread. Have the OpenGL thread read from a Threads::Queue and write to another queue to process the events. You might have luck in that, at least on Windows, the GLUT callbacks won't interfere with the OpenGL drawing stuff, so you can of course try to instantiate these callbacks from within their own thread.

Also, for all things asynchronous, look beyond threads at POE, which is an event-based framework and at Coro, which uses userspace threads and thus circumvents almost all synchronisation problems. The author of Coro also writes Deliantra, a multi-user game using OpenGL, so likely you'll be able to use OpenGL with Coro.

Threadsafe seems to explain it well. Basically, the problem is concurrent access to shared resources. Like everybody rushing to the bank to get money out at the same time. Except that threads don't naturally form block-busting queues.

Thanks to you as well, interesting reading there. I'm amused though by how they go "Every thread has access to virtually all the memory of every other thread." and in Perl it's the exact opposite, especially with complex data structures, which is the biggest stumbling stone to me threading my data processing subs.