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

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-08-02 22:19:35

Michael Glassford 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.
>>
>>>I'm working on a way to do this under VC6.  Please let me know if theres
>>>any other way I can be of assistance with regards to this.
>>
>>By the way, in your posting, you had this code:
>>
>>// Report thread and process detach events.
>>void NTAPI tls_callback  (PVOID, DWORD Reason, PVOID) {
>>
>>  if(Reason == DLL_THREAD_DETACH)
>>    on_thread_exit();
>>  else if(Reason == DLL_PROCESS_DETACH) {
>>    on_thread_exit();
>>    on_process_exit();
>>  }
>>}
>>
>>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.
> 
> I sent my last message too soon, before I mentioned that I'm aware that 
> the incorrect code was originally copied from my code. In thinking about 
> it, I also realized that, at least in the case of Boost.Threads being 
> built as a dll, there isn't a convenient place to call on_process_exit() 
> from and the name of the function is misleading (since the function 
> needs to be called when the dll is being unloaded, not necessarily when 
> the process is exiting).
> 
> So I'm considering the following changes:
> 1) Eliminating the on_process_enter() function, which is unnecessary ans 
> has a misleading name, and the on_process_exit() function, which is 
> difficult to call correctly and also has a misleading name.
> 2) Adding the new on_thread_enter() function.
> 3) Implementing a attached-thread-count scheme: on_thread_enter() 
> increments the count, on_thread_exit() decrements it, and when it 
> reaches zero on_thread_exit() calls TlsFree().
> 
> The DllMain() or tls_callback() functions call on_thread_enter() for 
> both the DLL_PROCESS_ATTACH and the DLL_THREAD_ATTACH messages, and they 
> call on_thread_exit for both the DLL_PROCESS_DETACH and 
> DLL_THREAD_DETACH messages.
> 
> This scheme seems a little cleaner and so far seems to be working OK. 
> Any thoughts about this?

Yes I think reference counting seems like a good idea here.

The only concern I have--I don't know how important this is--is that
when a thread is killed with TerminateThread, I think neither TLS
callbacks nor DllMain()s will be called.  This would cause the TLS count
to never reach zero, and for TlsFree to never be called.

These threads might not even be associated with the Boost TSS at all.
For example, another third party library in some DLL might be using
TerminateThread, and the application programmer may not even know about
this, so it may be suprising to him when the reference count never
reaches zero for apparently no good reason.

> Mike

Aaron W. LaFramboise