Re: Draft of generation 2 thread class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-20 22:29:51

--- In boost_at_y..., Tom Becker <voidampersand_at_f...> wrote:
> On Sun, 20 Jan 2002 20:10:40 -0000, "bill_kempf" 
> <williamkempf_at_h...> wrote:
> >  > 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.
> 
> I'm still confused and a little bit concerned. Let me try asking 
> again and hopefully more clearly:
> 
> 1) Is it correct that the thread function needs to have a top level 
> try/catch block in order for the thread to be exception safe?

That depends on the platform.  Typically it's undefined behavior on 
most platforms.

(Boost.Threads, however, will insure the application terminates if an 
exception isn't caught by a "boost" thread.)

> 2) In the current implementation, when the thread constructor 
starts 
> a new thread of execution, it actually starts the thread with a 
> thread_proxy function that has a try/catch block and calls the 
> threadfunc. This seems good to me. How is the equivalent process 
> going to work for an adopted thread?

An adopted thread is one that was created outside of Boost.Threads 
and subsequently "adopted", so how it works is platform specific.
 
> >  > 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.
> 
> I think your design is correct or very close to it. It's just that 
I 
> have been burned by poorly designed thread packages before, so I'm 
> always going to take a slightly paranoid approach to reading the 
> documentation, and I expect I'm not the only developer who may feel 
> that way.

No, don't take me wrong.  I truly thought I covered the bases in the 
documentation, but if things are unclear I have to work on it.
 
> 	disable_cancellations();
> 	Effects: Disables all requests for cancellation. Any further
> 	calls to any "cancellation points" will be ignored.
> 
> It's not clear to me what a "request" is. It could be the cancel() 
> function, or it could be the flag that cancel() sets, or it could 
be 
> what happens at the cancellation point. The first two 
interpretations 
> would mean the design is unreliable, the third would be good.

It's actually the second, but what I think is unclear is that I 
stated "any" further cancellation points when it's only any further 
cancellation points until cancellation is subsequently re-enabled 
(which results in your third description.)
 
> 	~disable_cancellations();
> 	Effects: Returns the cancellability of the thread to the state
> 	it was in prior to the construction of *this.
> 
> It isn't clear whether "restoring the cancellability of the thread" 
> applies to the cancellation flag or to the cancellation points, and 
> it could be read as "now I can call cancel and it will work", 
or "now 
> that call to cancel I made has a chance to take effect." The first 
> interpretation would mean the design is unreliable, the other one 
is 
> okay.

It's the latter.  I'll definately try and reword the documentation.  
Thanks for the input here.
 
> Here's some alternate wording that
> 
> 	disable_cancellations();
> 	Effects: Temporarily prevents cancellation requests from 
taking
> 	effect. Saves the prior disable state.
> 
> 	~disable_cancellations();
> 	Effects: Restores the prior disable state. If there are no 
more
> 	instances of disable_cancellations for the thread, and there 
is
> 	a pending cancellation request, the cancellation request will
> 	take effect when the thread calls a cancellation point.
> 
> This isn't perfect, but I hope it gives you an idea of what I'm 
thinking.

Yes.  However, I'm heavily leaning towards Dave's idea of counting 
the disables.

Bill Kempf