From: Steven Mauceri (sm_at_[hidden])
Date: 2003-03-29 17:54:26
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
The previous email about the current boost specification gets into more
detail about possible options in this space.
From: Edward Diener
Sent: Saturday, March 29, 2003 2:04 PM
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:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk