Yes, cleanup could be solved this way (or with other approaches, daemon thread, periodic timers, etc). However, I don't see cleanup as the core issue with making TLS work without a DLL under Win-32.
Currently, boost.threads supports (uses/specifies) the POSIX style cleanup model where the cleanup function is called on the thread that is closing. This cleanup function can also set/get/clear TLS values (which should continue to be valid for the "closing" thread until it exits [read: right after the cleanup func finishes]). Boost.threads TLS/DLL approach is used to fire off the cleanup function on the closing thread. There are also issues with this [DllMain single-dispatch rules, someone waiting in a cleanup handler, and others], but this approach at least allows boost.threads under Win32 to conform to it's own specification. [ Note: Windows internally seems to have been fixed by MS at some point to dispatch DLL_THREAD_DETACH in a "reverse-dependency" order, which makes sure that the DLL that was most recently loaded is the first to receive DLL_THREAD_DETATCH messages. Without this behavior, DLL TLS support would have serious issues in even working out of the box. The reason this seems to be a fix by MS at some point, is that the DLL_THREAD_ATTACH order is *NOT* in dependency order, but in what appears to be link order. Perhaps someone from MS can comment on the implementation, and how it came to follow these [undocumented] rules. ] For boost.threads stand-alone lib, the only solution I currently see is: - Relaxation of the cleanup function handler requirement from "WILL BE CALLED", to "MAY BE CALLED" from the closing thread. If this was done, then Unix implementations would continue working as is (call from cleanup func in closing thread), and windows implementation would have a worker thread(s) dispatch the cleanup handler functions when threads were shutdown (this thread would wait on the thread object when TLS values were in use on a particular thread). Note, the calls to the win32 boost TLS functions can be made to "work" correctly if dispatched from a cleanup-handler, which is what we want. However, OS level functions, [GetCurrentThread() and friends] would yield the thread of the "cleanup dispatcher" thread which is indeed incorrect. Since *few* people do "fancy" things in TLS [usually they deallocate/free resources], and *even less* people call other TLS functions from cleanup handlers, and *even less* people call OS-thread functions inside their TLS cleanup handlers, I see the change in the specifications to be reasonable. With something like this I see a valid (if complex in implementation) way to support boost.threads as a static lib. Willam Kempf has be gracious enough to discuss many of the issues at length with me and has examined various approaches to solving the TLS / DLL dependency issues. At first I thought it should be possible to solve, but I now feel that solving it within the scope of the current TLS-cleanup handler specification is impossible without modifying the specification (from WILL to MAY "call from the closing thread"). Here Bill and I disagree :-). Bill feels that the specification should not be changed, since this is an OS-brokenness issue that can be corrected by MS at some point in the future. I feel, that the boost thread specification should be modified for this (very rare) corner case, in order to support Win-32 static lib builds of boost.threads. I don't see any right or wrong here, as it is fundamentally a matter of specification. - Steve PS I also share Bill's desire to find a workable solution to this problem. However, I am pessimistic that there exist solutions that work under Win-32 and conform to the boost thread TLS spec rules for cleanup handlers. -----Original Message----- From: David Abrahams Sent: Saturday, March 29, 2003 10:16 AM > I don't really understand the issues here, but I was > wondering if you could reclaim "leaked" TLS resources > lazily somehow, by looking for unused TLS the next time > new TLS is requested. Just a thought... -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost