[Openal-devel] Thread-local contexts

Jason Daly jdaly at ist.ucf.edu
Thu Sep 10 12:06:51 PDT 2009


Chris Robinson wrote:
> 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 agree with you about option 2, I'd probably pick that one last.  3 is 
interesting to me (see below)...


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

How about alcMakeContextCurrent() following option 3 above, and 
alcMakeProcessCurrent() following option 1?  Newer apps would probably 
stop using alcMakeContextCurrent() in favor of the two new functions, 
while older apps continue to work as before.

--"J"



More information about the Openal-devel mailing list