[boost] Re: Windows MSVC thread exit handler for staticly linked Boost.Thread

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-08-02 20:23:01

Aaron W. LaFramboise wrote:
> Michael Glassford wrote:
> 
>>Aaron W. LaFramboise wrote:
>>
>>>Michael Glassford wrote:
>>>
>>>>Aaron W. LaFramboise wrote:
>>>>
>>>>>Following is an implementation of, and some comments on, a staticly
>>>>>linked Boost.Thread thread exit handler for MSVC.
>>>>>
>>>>>By the way, I appologize for talking so long to cough this up after
>>>>>posting teasing remarks about this months ago.  Programming is presently
>>>>>a hobby and volunteer work for me, unfortunately.
>>>>
>>>>Thanks! I've been looking forward to you posting this, and it appears to 
>>>>work beautifully for VC++ 7.1 (as others have already commented). Do I 
>>>>have your permission to included it in Boost.Threads under the Boost 
>>>>license (with your name on it, of course)?
>>>
>>>Yes, you and anyone else have perpetual permission to offer it under any
>>>license you choose.
>>
>>Thank you. It's in, and will be in the upcoming release. A lot of people 
>>will be happy, including me! I look forward to the GCC version as well, 
>>though I haven't yet used GCC myself.
> 
> 
> Make sure you look at Roland's code that gets MSVC6 right by doing a
> fixup that fixes a problem in the TLS support code.  That fixup should
> only be done on MSVC6 though.

I definitely will. I was under the impression that it was still under 
construction, but if it's ready, I'm interested.

> For GCC/MinGW, I'm actually adding an API that gets all of this right:
> an atexit variant that knows about module unloading and thread
> destruction.  Ideally all compilers would have such an API to make these
> sorts of problems easy. :)
> 
> 
>>If I understand what DLL_PROCESS_DETACH means (the thread is being 
>>notified that it is being detached because the  process is exiting), the 
>>call to on_process_exit() is incorrect; on_process_exit() is meant to be 
>>called when the process actually exits (it calls TlsFree()). The most 
>>likely place to call it is at the end of main() or after the main thread 
>>exits.
> 
> 
> Well, as near as I can tell, when the TLS routine is called with
> DLL_PROCESS_DETACH, this will be the absolute last user code executing
> in the process, including DLL destructors.  As far as I know, once you
> return from DLL_PROCESS_DETACH in the TLS routine, no more user code
> will run.

Is it called only for the last thread to detach, or can it be called for 
more than one thread? Does it work the same for tls_callback and DllMain?

Mike