[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