notable here is that using wglShareLists, it is apparently possible for multiple threads to both access OpenGL (at least on Windows...).
(ADD: apparently in the Linux case, it is mostly as an argument to glXCreateContext).
this is, in effect, pretty nifty.
however, I am doing this in a slightly funky manner:
effectively, work-items are submitted via a "work queue", with worker threads which grab items off the queue, then invoke their supplied function-pointers.
(this being in contrast to using a dedicated thread for the task).
previously, there was no way of saying which worker thread would get which work items, so there was a potential issue of OpenGL-specific work-items being grabbed up by a worker thread which didn't have OpenGL available.
a solution then was to add the concept of a worker-ID (and make some "clever" changes to the work-queue code), where worker creation functions could be "registered", which would return an info structure containing function-pointers to be called when beginning/ending execution of the new worker thread (or also deny creation of new workers), ... and making it so that work-items would only be executed with a worker of the matching type (the default/generic workers were then given an ID of 0).
a little logic later, and now I seem to have worker threads which can access GL (and things like rebuilding the terrain can now happen asynchronously, and is also a little bit faster).
(granted, yes, did have to go add mutexes and similar in a few places... mostly as the terrain-building code wasn't exactly thread-safe).
Edited by cr88192, 16 March 2013 - 12:41 PM.