Edward Diener said: > "William E. Kempf" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> >> Edward Diener said: >> > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message >> > news:[EMAIL PROTECTED] >> >> >> >> Ken Hagan wrote: >> >> > >> >> > Alexander Terekhov wrote: >> >> > > >> >> > > I, for one, believe strongly that "&k" is nothing but >> >> > > >> >> > > "static_cast<typeof(k)*>(pthread_getspecific(__k_key));" >> >> > > >> >> > > It *isn't* a compile-time constant (just like &errno isn't a >> >> compile time constant). >> >> > >> >> > MSVC has no pthread_getspecific(), so I venture to suggest that >> your >> >> belief probably isn't valid for that compiler. >> >> >> >> Uhmm. In return, I venture to suggest that MS-TLS can and shall be >> characterized as ``utterly busted.'' >> >> >> >> "If a DLL declares any nonlocal data or object as >> __declspec(thread), >> >> it can cause a protection fault if dynamically loaded." >> > >> > This is well-known by many and has never been hidden by MS. It >> doesn't mean __declspec(thread) is busted, it just means that it is >> limited to only those cases in which the DLL is not dynamically >> loaded, which is the vast majority of cases. Of course to make TLS >> completely foolproof, one does not use __declspec(thread) but >> instead one uses the Win32 TLS API functions instead. >> >> Where you run into issues with TLS cleanup ;). > > Such as ? > > You can clean up your own TLS index ( or indices ) in your DllMain > routine when the seond parameter is DLL_PROCESS_DETACH, meaning that > your process is being exited. AFAIK this is the standard way to do this.
(Note: The issue is more with cleaning up TLS data then with cleaning up TLS indices/slots. So we're really talking about DLL_THREAD_DETACH here.) This is the MS way, not the "standard" way. And it's full of issues. You are quite limited in what you can safely do within DllMain. Any calls to synchronization routines is likely to deadlock the entire process. As is calling any routines that load/unload a DLL. There's also the issue of forcing the use of a DLL with this scheme, which many users rightfully dislike (this is why there are so many thread creation routines on Windows). >> I won't be as critical as Alexander, but I will agree that the MS TLS >> implementation has serious design issues which need to be corrected. > > OK, this isn't the place to debate Windows TLS, but I have not run into > such design issues myself. You have, you just weren't necessarily aware of it ;). Again, I point you to the various thread creation routines as the number one issue that we've all encountered. If you've needed to do complex cleanup, or wanted to not have to deal with a DLL, then you've run into the other problems more directly. This has been the biggest issue with implementating thread_specific_ptr<> for me, and what we have today is quite ugly and fragile. And I do think it's a proper place to debate Windows TLS. It directly effects Boost.Threads, and the more people we make aware of the problems, the more likely something will be done about it. -- William E. Kempf _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
