Re: Draft of generation 2 thread class

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

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

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.
 
Bill Kempf