Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-17 12:50:14

--- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > ----- Original Message -----
> > From: "terekhov" <terekhov_at_d...>
> > To: <boost_at_y...>
> > Sent: Thursday, January 17, 2002 5:10 AM
> > Subject: [boost] Re: first sight
> > 
> > 
> > > --- In boost_at_y..., Tom Becker <voidampersand_at_f...> wrote:
> > > > >4) Allow the user to "eat" the exception.
> > > > >5) Make the cancellation "flag" a sticky flag, so if the
> > >
> > > I would much appreciate if someone would explain me
> > > the usefulness of N4 and N5 (other than ability
> > > to play tennis, I mean N4 handler and cancel.point/
> > > thread::exit(...)).
> > 
> > If a thread has a considerable amount to do in order to shut down 
> cleanly,
> > this allows it to yield control of the processor several times in 
a
> > controlled manner before finally exiting.
> 
> Hmm.. Do you mean sched_yield() or sleep() or 
> perhaps something else... ? I just still do not 
> see how killing thread-cancel/-exit exception 
> could ever help someone to do something better, 
> especially taking into account N5. On the 
> other hand, I see a possibility that e.g. 
> { cancel(victim); join(victim); } could block 
> forever... despite the fact that cancellation 
> was enabled and victim continuously hitting 
> cancel.points and eating CPU, instead of going 
> to nirvana and freeing space for coming generations. 
> I also see some moral issues wrt thread::exit 
> (a thread should have a right to die! all 
> functions equal!! ;-)

cancel(victim); join(victim); can block forever even under the 
current POSIX definitions, even when cancellation is enabled (though 
not when asynchronous cancellation is enabled).  Mr. Butenhoff agreed 
with our decisions on N4 and he doesn't address N5 in any way, so 
we're left to assume he thinks its valid (even if not recommended, 
thus N7).

> > > Why not just say that it is *undefined* behavior?
> > 
> > Because we can do better and saying "undefined behavior" doesn't 
> buy any
> > useful implementor flexibility in this case.
>  
> To me, the best would be to KILL such broken appl, ASAP!

There's nothing broken, unless the thread simply never dies.  N5 
makes it very difficult for that to happen, and if it does that's 
simply a user error and not something wrong with the API design.  
Again, POSIX currently gives the same gaurantees (or lack there of) 
in this regard.

Bill Kempf