Re: Re: Draft of generation 2 thread class

From: Tom Becker (voidampersand_at_[hidden])
Date: 2002-01-20 03:29:39

On Sat, 19 Jan 2002 17:10:00 -0000, "bill_kempf" 
<williamkempf_at_[hidden]> wrote:
>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.

Thanks,

   Tom

-- 
--
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