To be clear, what I'm proposing requires ZERO code changes to Wine and glibc. It will work today, with Wine implementations already in the field. All I'm proposing we do is make sure it continues to work in the future, irrespective of the decision made regarding the use of glibc's new __thread variable support.
If it turns out glibc's new __thread variable support really can do what you need on all platforms, do you agree that it might be better to use that?
As I said in my last email, there are some unresolved issues with using __thread variables:
1) We need fast TLS access on platforms where __thread variables are not supported.
Which platforms are those? I didn't see this in your previous email.
2) libGL.so must be able to be dynamically loaded. Failing to dlopen libGL.so will, at the very least, make the entire Linux gaming community very unhappy :-)
Agreed. I think the authors of the new __thread support agree, too.
3) It is unclear how online generated code can interact with __thread variables. Perhaps this is simpler than I think...
- Dan
-- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
