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

From: Malcolm Noyes (boost_at_[hidden])
Date: 2004-06-11 00:19:16

<snip>

>I appologize; I misspoke on the fact that the MSVC support is complete.  
>I beleive this has something to do with missing support in tlssup.obj, 
>but I'm limited in my ability to investigate due to intellectual 
>property issues.  Not too sure how to handle this.

This is an interesting possibility, however there are references in
the archives to Bill Kempf having discussions with folks at Microsoft
about how to fix tss/tls cleanup on Win32; unfortunately he doesn't
reveal whether using TLS callbacks was suggested, so we don't know if
it has already been considered, and possibly rejected.

>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 :-(

>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 ?

>So, well, I have no idea how helpful this is to anyone, and I'm 
>painfully aware of how hypocritical it is to not be able to provide a 
>simple testcase.  I just wanted to let people know that Windows seems to 
>have this capability, and that the GNU environment on Windows will 
>probably support this sometime soon.

It's certainly interesting;  like you though, I'm not convinced that
it will solve the general case :-(

Malcolm
Malcolm Noyes