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