Boost logo

Boost :

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,

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at