Notes about multithreading
-
First of all, if your application uses non-shared processes rather
than threads, you don't need any special considerations since the
GLAF internal contexts data won't be shared across processes.
-
If your application has several threads (or share-group processes
created through 'sproc') but only one of them is used
for GLAF and for OpenGL rendering in all contexts, you don't need special
considerations either.
-
If your application uses a different thread (or share-group process
created through 'sproc') for each OpenGL context, but you just
need one GLAF context (see 'Alternative contexts management' at
the 'Basic Use' page for details on what situations
let you use one GLAF context for several OpenGL contexts), you don't need
special considerations either (ie, GLAF is thread-safe in this case, except
the emulation mode of Copy Texture, so you may want to call glaf_IsCopyTextureNative
for knowing whether Copy Texture is emulated or not).
-
Otherwise, if each thread in your application needs to call
glaf_ReadyForContext, you need to provide some locking/unlocking:
First, creation and destruction of GLAF contexts should be locked. Second,
you should lock all the work of one thread since before it calls
glaf_ReadyForContext until the last call to a GLAF function in the
current redraw. Note that this may increase your performance rather than
decreasing it, because this locking will lower the number of context switches,
and so, in general, increase OpenGL performance, which is not usually tuned
for a zillion of context switches per second.
-
If for some reason you really need a reentrant GLAF for all situations,
please contact me.
|
