On Thu, 29 Jul 2004 14:02:18 +0200 Bronek Kozicki <brok@rubikon.pl> wrote:
When his mainCRTStartup (or DllMainCRTStartup) is executed, this symbol will be initialized by call to TlsAlloc (ie. inside function _mtinit).
Don't know what you mean by this? There is _ever_ only one mainCRTStartup in any single executable! If there where more consequently main() would be multiply invoked, which is definitely not the case. My only point is: whoever causes your module beeing called _must_ have been starting his thread by _beginthread. Because only this allocates the struct _tiddata. Note that this has nothing to do with TlsAlloc which of course, as you pointed out already has delivered a slot index at process startup. (Whoever called mainCRTStartup.)
This is enough to initialize TLS index for CRT. Because this index is shared (linker did this) with static CRT your static library is linked with, effectively it will share TLS with CRT linked (statially or dynamically) with code of your client. At least this is my idea of what linker is doing, and I've confirmed that with debugger. And this is enough; execution of TlsSetValue and initialization of CRT data is delayed to first access of CRT TLS data through _getptd function (defined in tidtable.c).
Ahhh. Now I understand what you are talking about! You convinced me. But then what happens at thread exit? During DLL_THREAD_DETACH the _tiddata has already been deallocated during _endthread. Now if one again accesses one of the CRT functions during DLL_THREAD_DEATCH this would cause _getptd to reallocate _tiddata for this thread. Hmm. This will also account for a memory leak. Wouldn't it? But it definitely will not result in an access violation. While the situation is not as bad as I was afraid it could be, it still would be better to be able to call the tls cleanup code from within _endthread, and not DLL_THREAD_DETACH. Thank you for this insightful discussion so far. Roland