<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