[Openal-devel] Thread-local contexts

[Chris Robinson]

On Wednesday 09 September 2009 6:01:55 pm Jason Daly wrote:
> Yes, alcMakeContextCurrent() is what I meant.  That seems a bit
> counter-intuitive to me.  Would it be better (after an
> alcMakeThreadCurrent() call) for an alcMakeContextCurrent() call to set
> the specified context current for both the global and the thread context?
> 
> I guess no, because the whole point of this is to kind of "override" the
> current context in your own thread while some background thread that
> probably wasn't written with this extension hums along on its merry way.

Right. Existing code needs to work as it has, and new plugins or background 
code that use this new extension need to be able to work with other code that 
may or may not be aware of the extension.

alcMakeContextCurrent must not change the thread-local context if the thread-
local context is NULL. If the thread-local context is not NULL, then whether 
it's changed or not doesn't matter too much since only the running thread will 
affect it. If the app gets into code that wasn't aware of the previous call to 
alcMakeThreadCurrent on the same thread, it's in trouble anyway.

It just seems more intuitive to me to make alcMakeContextCurrent not affect 
thread-local contexts, as the function wasn't made with thread-local contexts 
in mind. Plus it can't change it away from NULL, so changing it away from non-
NULL would be inconsistent, IMO.

> It just seems odd that alcMakeContextCurrent() might not make the
> specified context current in some cases.  I can't think of an
> alternative at the moment, though.

It does make it current, it just won't immediately affect threads that have a 
thread-local context set. Something like this:

alcMakeThreadCurrent(ctx2);
...
alcMakeContextCurrent(ctx1);
...
alcMakeThreadCurrent(NULL);

would end up with ctx1 as the current context for the thread.