From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-20 15:10:40
--- In boost_at_y..., Tom Becker <voidampersand_at_f...> wrote:
> On Sat, 19 Jan 2002 17:10:00 -0000, "bill_kempf"
> <williamkempf_at_h...> wrote:
> >The boost::thread class maintains state information that's placed
> >thread local storage (and then simple pointers to this data are
> >placed in each object instance). If a thread was not created using
> >Boost.Threads this thread local data won't exist (and the pointer
> >the object will be set to NULL). The fly in the ointment comes
> >when we need to call methods that require this Boost.Threads
> >state data for the "platform" threads. Thus the need to "adopt"
> >threads. The adopt() method will allocate the needed state
> >information and place it in the thread local storage, thus
> >a "platform" thread to a "boost" thread.
> >Because of the different requirements for cleaning up the various
> >state information (platform and Boost.Threads) it's up to the
> >programmer to insure that adoption "follows the rules". If it's
> >a "platform" thread then platform specific methods must be used to
> >manage the state's lifetime and if it's a "boost" or "adopted"
> >then Boost.Threads specific methods must be used. So we can't just
> >arbitrarily adopt threads implicitly.
> That all makes sense.
> In the threading systems I've used, the each thread's main function
> must catch all exceptions, otherwise bad things can happen. When
> boost adopts a thread, is that before the thread is running so
> there's still a chance to get an exception handler onto the top of
> its stack? If not, how will an adopted thread keep exceptions
> contained to the thread?
There's no way to adopt a thread before it exists. No, thread
adoption won't have any impact on exception safety. This is one area
where we need language support and the library can't help us.
> It occurred to me that maybe the disable_cancellation class should
> defer cancellation, rather then prevent it. It isn't clear in the
> documentation which of the two behaviors it will have. The reason
> deferred cancellation is so the application doesn't have to keep
> trying to cancel a thread until it finally succeeds. Implementation
> would be simple: disabling/deferring cancellation doesn't prevent
> cancel flag from being set, just from being acted on.
I thought the documentation covered this well enough. Nothing ever
prevents another thread from requesting the thread be cancelled.
Disabling simply means that cancellation points do not throw
regardless of any such pending requests.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk