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