[Openal-devel] Thread-local contexts

[Chris Robinson]

An idea I've been juggling around in my head. Unlike OpenGL, OpenAL only has 
one current context per process. While this can help for things like sharing 
sources between threads, it creates big problems when two subsystems may want 
to independently use OpenAL.

For example, if something like DirectShow or GStreamer wants to use OpenAL to 
stream out music/audio, separately from the app which uses OpenAL for game 
sounds, it creates a problem where the background music player needs to set 
its own context for its device, while the main game needs to set *its* context 
for its device. There's no way for a background player to sanely work without 
exposing specific controls and requiring specific interaction with the main 
app, and this still wouldn't work for existing apps that may not expect their 
background player to suddenly start using OpenAL.

If the background player could set a thread-specific context, it would prevent 
unexpected side effects in the rest of the app. The app setting its own 
(global) context wouldn't affect the current context for the background 
player, and vice versa.


My idea would be to leave alcMakeContextCurrent set a process-wide context, 
while a new function (alcMakeCurrent, alcMakeThreadCurrent, ..?) would set a 
thread-local context. With a thread-local context set, the thread will ignore 
the process-wode context. If a thread-local context is set to NULL, then the 
process-wide context will be used for the thread. So basically, in psuedo-
code:

ALCboolean alcMakeThreadCurrent(ALCcontext *ctx)
{
    if(!ctx || IsContext(ctx))
    {
        tls_current_context = ctx;
        return ALC_TRUE;
    }
    ...
}

ALCcontext *alcGetCurrentContext()
{
    ALCcontext *ctx = tls_current_context;
    if(ctx == NULL)
        ctx = global_current_context;
    return ctx;
}

This allows alcMakeContextCurrent to behave the same for existing code, while 
new code can affect just the thread's current context, within the same app.