[Openal-devel] Thread-local contexts

[Jason Daly]

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

I'm thinking more from an API/terminology perspective.  What you're 
essentially saying is that the specified context is now current, but the 
thread-local context that you set earlier is "more current."  To me 
"current" seems like an absolute term.  Either the context is current 
(and you can manipulate it), or it isn't, so I would disagree 
(conceptually) that a call to alcMakeContextCurrent() will make the 
context current in all cases.  If there is a current thread-local 
context, alcMakeContextCurrent() won't make the given context "current" 
because you can't manipulate that context until you set the thread-local 
context back to NULL.

If this extension is implemented, someone that is new to OpenAL may 
expect that a call to alcMakeContextCurrent() will ensure that they will 
be able to manipulate the specified context, and they may be confused 
that it doesn't because they had previously set a thread-local context 
and never set it back to NULL.  This would be easy to find in a simple 
program, but as the programs gets larger (especially a multi-threaded 
program, which is what this extension is targeting), it might get more 
difficult to track down the problem.  (Keep in mind that I work at a 
university research lab, where we routinely have inexperienced 
programmers working on relatively complex software systems  :-) )

I still don't have a better idea, though.  The simple answer would be to 
change the API terms to make them more intuitive.  Say, change 
alcMakeContextCurrent() to alcSetDefaultContext(), which intuitively 
suggests that the "default" context can be overridden by other 
thread-local contexts.  However, I think everyone would agree that 
changing alcMakeContextCurrent() isn't really an option.

--"J"