From: Roland (roland.schwarz_at_[hidden])
Date: 2004-07-29 08:25:18
On Thu, 29 Jul 2004 14:02:18 +0200 Bronek Kozicki <brok_at_[hidden]> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk