Re: [boost] Re: Thread lib (good reason for static)

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-06-11 00:39:12

Malcolm Noyes wrote:

>>It is my intention to get this feature working 100% on GNU GCC and 
>>binutils, which I admit are my primary interest, but I am unsure about 
>>MSVC.  I am very hesitant to investigate MSVC any more than necessary as 
>>I do not want to get myself into ridiculous IP problems.
>>    
>>
>
>Unfortunately MSVC is probably what most people will be using :-(
>  
>
Well, I think it might be possible to get it working by linking against 
a replacement for tlssup.obj that will do the right thing.  In fact, I 
happen to have such a replacement that was used with GCC to get static 
TLS to work, but I haven't tested it.  I think it could be made to work 
for MSVC.  As mentioned, I also plan to have it working reliably with 
GCC.  Between GCC and MSVC, perhaps we have enough compilers to have a 
good basis for implementation.  And since TLS callbacks are standard, 
who knows, maybe they're easy to get working on other compilers too.

>>I also neglected to mention that this feature may be unusable, in 
>>general, because the TLS callbacks are called before the C library's 
>>are.  This means that stdio and the heap may not be fully availible, at 
>>least for MSVC.  The standard C library (and perhaps other DLLs?) need 
>>to expect that they may not be notified first of ctors/dtors.  MSVCRT 
>>may do this, but I am not sure.  I don't know what garentees there are 
>>about MSVCRT.DLL being notified before any other loaded DLL, anyway.
>>    
>>
>
>Hmm. So an application whose tls cleanup required 'C' library
>functions would probably fail. An application that required a TLS
>cleanup handler that (for example) aquired a process shared mutex,
>fiddled with some process shared memory and then released the mutex
>might work, but would anyone like to guarantee it (without support
>from Microsoft)?   I know that this is a 'corner case' that some would
>consider boost::thread doesn't need to support; my imagination has run
>as far as a monitoring application that uses a process shared mutex to
>'watch' the threads created and destroyed by some other application
>(the one that we want to test) - I have applications now where a
>utility like this could be useful.  You could do this by allocating a
>thread_specific_ptr object that recorded the process id, thread id and
>optional name of the thread on thread startup; thread_specfic_ptr
>object destruction would remove the thread from the list in the
>'monitoring' application. Another way to do this would be to use
>sockets - anyone like to wager anything on whether this might work
>with TLS callbacks ?
>  
>
I'm not sure exactly what happens.  It needs testing, but in any case, 
I'm sure there are no documented garentees.  I also think some hack to 
work around problems, if they are problems, could be made to work reliably.
I do feel fairly strongly that the ability to nondeterministically call 
destructors for objects in dynamic TLS is important, and acheivable, 
somehow.

The "I think this can work but I can't really say for sure" is due to me 
not having time to tear into this yet.  Since interest in this mechanism 
has been indicated, I will definitely look into this and get the answers 
with regards to its usability within a few weeks.  Hopefully then I will 
be able to say more definitively, "Yes, Boost can use this, and this is 
how" or whatever.

Aaron W. LaFramboise