The bad news is that the combination of a multithreaded app, with an "old" driver, and a "new" libGL will result in a segfault. The code sets _glapi_Dispatch to NULL in the multithreaded case as a signal to call _glapi_get_dispatch. When the code is fully converted to TLS, the call to _glapi_get_dispatch will be replaced with a 'movl %gs:_gl_DispatchTSD, %eax' or something similar.
I want to maintain compatibility across the whole matrix of old / new libGL with old / new drivers. I may be willing to sacrifice new driver + old libGL, but that's the only combination I'd be willing to give on. I think we need to do 3 things to get there:
1. Keep the old meaning of _glapi_Dispatch. This means that all the _ts_* functions and their support mechanism will have to be kept. :( However, it will only be needed for the DRI libGL. The software rendering Mesa version won't need it.
2. For non-TLS "new" code, implement a new variable called _glapi_DispatchTSD that implements the new behavior. There will be a "weak" version of that variable, that is always NULL in dri_util.c. This should allow non-TLS "new" code to work with old libGL binaries.
3. TLS "new" code can do whatever it wants. I imagine this will be a __thread variable called _glapi_tls_Dispatch or something similar.
That /should/ allow support of all 4 non-TLS combinations and allow the TLS libGL to work with non-TLS drivers. However, this will defeat some of the size and linkage (prelink, etc.) benefits of the non-compatible version. I'll see if I can work something up and send out a new patch tomorrow.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
