Dan Kegel wrote:
It does look like the TLS model does what you want it to, and no new methods are needed. Can you explain in more detail why your new proposal is needed, if you still think it is?
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.
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. 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 :-) 3) It is unclear how online generated code can interact with __thread variables. Perhaps this is simpler than I think...
-- Gareth Hughes (gareth@nvidia.com) OpenGL Developer, NVIDIA Corporation
Gareth Hughes wrote:
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:
- 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.
- 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.
- It is unclear how online generated code can interact with __thread
variables. Perhaps this is simpler than I think...
- Dan
Gareth Hughes gareth@nvidia.com writes:
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.
This is not something we can guarantee. The layout of the thread structure in Wine is defined by Microsoft, and it's very possible that they will use these fields someday for something that we need to emulate.
-
Alexandre Julliard -
Dan Kegel -
Gareth Hughes