[Openal-devel] Thread-local contexts

[Chris Robinson]

On Thursday 10 September 2009 8:31:04 am Jason Daly wrote:
> 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  :-) )

Could make it so alcMakeContextCurrent resets the thread-local context back to 
NULL, so whatever context is set will affect the current thread as well as 
other threads that don't have a thread-local context.

Then there's three possible options:
1) alcMakeContextCurrent doesn't change the thread-local context, so the 
current thread-local context will continue to be the 'active' context for the 
thread if it's non-NULL.
2) alcMakeContextCurrent changes both the thread-local context (if non-NULL) 
and global context to the specified value, so the active context will be 
whatever is set, for the current thread and any others that don't have a 
thread-local context.
3) alcMakeContextCurrent resets the thread-local context to NULL and the 
global context to the specified value, so the active context will be whatever 
is set.

All three should maintain current behavior for existing apps, but I still find 
option 1 as the most intuitive (it affects thread-local contexts of all 
threads the same; ie, doesn't touch them). However, option 3 could work, if 
you think that's the best way to go. I'd just be cautious with option 2.

> 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.

I see alcMakeContextCurrent as setting the global, process-wide context, while 
alcMakeThreadCurrent sets the thread-local context. When a thread-local 
context is set, it overrides the the process-wide context for that thread. I 
could add an alcMakeProcessCurrent that just aliases alcMakeContextCurrent, 
but that doesn't seem too useful since the original function will still exist.