Re[2]: [boost] Re: Re: Re: Threads Rewrite?

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.

Roland