[Openmcl-devel] OpenGL and threading

Lawrence E. Bakst ml at iridescent.org
Fri Jun 9 17:29:22 PDT 2006


This was recently discussed on the mac-opengl list. I copied some relevant excerpts below. Hope this helps.

Best,

leb

At 5:21 PM -0400 6/6/06, David Duncan wrote:
>OpenGL is threadsafe in-so-far that you can call the APIs from multiple threads at the same time. However you cannot be in the same OpenGL context on two different threads, that is not threadsafe and will require you to do your own locking. You can configure the context on one thread, then use it on another thread (I've done this for the same reason myself) and then you don't need any locking either, as long as you take care not to touch the context on both threads at once.
>--

At 4:59 PM -0700 6/6/06, Chris Niederauer wrote:
>I should have also mentioned that we added new API in 10.4 that allows NSOpenGL contexts to be used with multithreading by calling CGLLockContext and CGLUnlockContext around all of your OpenGL calls.  
>It can be used outside of NSOpenGL as well, if you'd like.
>
>You can read up on multithreading and OpenGL in our new OpenGL Programming Guide for Mac OS X in the "Multithreading and OpenGL" section:
><http://developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/>




At 6:14 PM -0600 6/9/06, Gary Byers wrote:
>This is more of a stab in the dark than a suggested workaround, but
>the stab worked a few weeks ago and seems worth another try ...
>
>OpenGL contexts are bound per-thread; if a given thread hasn't
>established a context (via some Cocoa/AGL/GLUT mechanism), then
>any OpenGL call made in that thread that requires a GL context
>will crash and burn (and segfault.)
>
>I -think- (and I'd have to read the docs and double-check) that
>GL is otherwise not thread-safe in and of itself; that if you
>did something like:
>
>? (process-run-function "background GL thread"
>      #'(lambda () (setup-opengl-context ...) (some-sort-of-event-loop)))
>
>and also did (in a listener):
>
>? (setup-opengl-context (same-context-as-background-thread))
>
>that you'd have to provide your own locking/synchronization mechanisms
>- or depend on luck - to avoid problems.
>
>(It would be good if I was mistaken about that.)
>
>On Fri, 9 Jun 2006, Kaveh Kardan wrote:
>
>> I'm calling an OpenGL-based library from OpenMCL, following the
>> example given in the distribution.  The example runs OpenGL/GLUT in a
>> thread, so that the listener can be active.
>>
>> The problem I'm running into is any interactive code which invokes
>> OpenGL calls (and is therefore not running in the same thread as the
>> OpenGL process), causes a crash.
>>
>> Does anyone have a suggested workaround?
>>
>> Regards,
>>
>> Kaveh
>>
>> Kaveh Kardan                 Chief Technologist
>> kaveh at hawaii.edu             Academy for Creative Media
>> (808)956-5302                University of Hawaii
>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
>_______________________________________________
>Openmcl-devel mailing list
>Openmcl-devel at clozure.com
>http://clozure.com/mailman/listinfo/openmcl-devel





More information about the Openmcl-devel mailing list