From: Tom Becker (voidampersand_at_[hidden])
Date: 2002-01-20 03:29:39
On Sat, 19 Jan 2002 17:10:00 -0000, "bill_kempf"
>The boost::thread class maintains state information that's placed in
>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 in
>the object will be set to NULL). The fly in the ointment comes about
>when we need to call methods that require this Boost.Threads specific
>state data for the "platform" threads. Thus the need to "adopt" such
>threads. The adopt() method will allocate the needed state
>information and place it in the thread local storage, thus promoting
>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" thread
>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?
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 for
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 the
cancel flag from being set, just from being acted on.
-- -- Tom Becker "Lesson zero: pointers are not your friends. Consulting Propeller Head Lesson one: side effects are not your friends. <voidampersand_at_[hidden]> Lesson two: pointers are your friends." -- Scott Myers
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk