Michael Glassford wrote:
"Johan Nilsson" <johan.nilsson@esrange.ssc.se> wrote in message news:c9k069$9jf$1@sea.gmane.org...
[following is windows-specific stuff]
I seem to recall that the reason for requiring a dynamically linked
version
was solely for automatically cleaning up thread_specific_ptr's at
thread
exit - is that right?
Yes.
There is a little-known mechanism present in the Windows executable support, called TLS callbacks, that can call a list of arbitrary functions when a process starts and exits, and when threads attach or detach (very similar to DllMain). The calls are made in the context of the relevent thread. No linked DLL or overriden or special thread functions are necessary, as with ordinary approaches. Its likely that few people know about this because there are apparently no compilers that use it--that I am familiar with. It is presently only documented in the PE specification. However, it appears to work without problems on all versions of IA32 Windows, and quite likely on anything else that uses PE, also. Support for it requires minimal compiler support (the ability to emit data in arbitrarily-named sections, or even better, support for constructors and destructors in __declspec(thread), which no compiler I am familiar with has, including MSVC), a linker that minimally supports TLS, and possibly some "glue code" to support the linker. Presently, MSVC has the necessary support, and GNU targets MinGW and Cygwin have all of the critical support as well, but lack the "glue." The way to do it is to emit a pointer to the function to be called (which has the same signature as DllMain) in any of the 25 sections .CRT$XLA through .CRT$XLY. The linker merges all of these sections into a single null-termniated table of function pointers and creates a pointer to it from the executable image's TLS directory. I am presently using this feature on the GCC target MinGW for this purpose. I have not distributed my code, though, so there is no widespread testing. I am also not sure what the limitations are with regards to what functions may safely be called from the context of one of these callbacks. I assume it is similar to DllMain(), which it makes it dangerous to use this as a general-purpose mechanism to execute arbitrary code. In particular, constructors often load DLLs as a side effect, particularly if lazy loading is being used, and this may cause difficult to diagnose or reproduce problems if one such constructor is being used in a TLS construction or destruction context. More research is required in this area. In any case, I think this mechanism is definitely something that should be examined if static thread support is being considered. Aaron W. LaFramboise