Thread fun

[renanse]

Ok, so first let me say please read it before you say "Stay with one thread"

Unfortunately, I can't.  I am writing a support library that renders 3d graphics using pbuffer only.  It works great except that the library can get called from multiple threads.  I don't want to (and don't have to) support concurrent calls...  That's already checked for.  I simply have to be able to service one thread that tells me to render xyz, then service another thread.  These threads may occur over the lifetime of an app using the library, or may simply be the result of unloading one app in the jvm and running another.

The problem I bump into is of course Context.  If a second thread comes along and wants to use the pbuffer, it's call to makeCurrent results in a stack explaining that the other thread already has context.

I have discreet points of entry and exit for each thread where I could ideally say "Ok, you have the ball Thread A" and "Ok now give me back the ball so I can pass it to the next Thread"  I need to do so without destroying the pbuffer (if possible) and definitely without destroying the threads that are calling the pbuffer (which pbuffer.destroy() seems to do.)

Anyone have any ideas?  I've tried GLContext.setContext(null) as well, to no effect.

[elias]

How about doing it like the JVM presumably does in recent java2d-on-opengl? that is, have one thread (privately to you library) that does all the rendering. All other threads calling your library simply passes commands the the render thread through a synchronized command queue.

- elias

[renanse]

Sounds too easy to work... hehe.  Thanks for the idea, should've thought of that myself.  :oops: