I believe you still have the problem of cleanup handlers needing to execute within the closing thread (before the thread exits).
One can call WaitForMultipleObjects() with a cleanup-worker thread whenever TLS is used, but you would only be able to execute the cleanup handler function (for the closing thread) within the cleanup-worker's context. This would allow the cleanup handler to execute from a cleanup-worker thread, before the thread object was actually closed. If the boost TLS specification were relaxed to allow for cleanup handlers to execute from a different thread (with boost.thread's Get/Set TLS methods working), I see the possibility for a boost.threads static-lib solution. The previous email about the current boost specification gets into more detail about possible options in this space. - Steve -----Original Message----- From: Edward Diener Sent: Saturday, March 29, 2003 2:04 PM To: [EMAIL PROTECTED] Subject: [boost] Re: Re: Thread Lib and DLL > Of course one might be able to roll's one own > thread local storage implementation, probably > using std::map<> to map a thread-id against storage > areas for a particular thread, etc. etc. which would > allow one to gain access to another thread's storage > areas for thread specific data in order to do lazy > reclamation, but one would have to do a good bit of > work in order to accomplish what TLS automatically > gives you. Also, of course, one's own implementation > of TLS would not be compatible with the end-user's > normal thread-local storage if that matters. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
