I knew that blog, but I expected to find the necessary data somewhere in
the "undocumented" (but still available) structures.
But I had to dig a little deeper into ntdll myself and came up with a
patch that is part of the multithread-support for DLLs:
http://d.puremagic.com/issues/show_bug.cgi?id=3885
It emulates the behaviour at process startup time, and modifies the data
structures so that windows handles the DLL as if it was loaded with the
process. This has the nice benefit that you don't need to handle the
creation of new threads.
The downsides are:
- DLL-unload is disabled, but I think unloading a DLL that uses TLS is
problematic anyway)
- It will leak some pointer-arrays in favor of not causing crashes due
to other threads using TLS at same time as reallocating these arrays.
As XP is not a fast moving target anymore, I hope that ntdll will not
change a lot, so it will not need adjustment for every windows-update.
I've checked SP2 and SP3, which look very much the same with respect to
TLS implementation.
Rainer
Don wrote:
Rainer Schuetze wrote:
Hi,
as I'm also hitting some problems with DLLs, here are some issues that
I am now aware of (sorry, can't tell for linux shared objects, but I
guess the situation is similar):
1. For D2, there is a major blocker with DLLs loaded after
intialization on XP because of no TLS support from the OS. There is a
simple workaround for single-threaded application (just setting FS:2c
to a pointer to _tlsstart), but I'm considering a full emulation of
the TLS initialization.
That's incredibly difficult. Have you read this?
http://www.nynaeve.net/?p=189
It'd be great if you can get it to work. But I fear that for Win32, DMD
is going to have to switch to explicit TLS.
