From: terekhov (terekhov_at_[hidden])
Date: 2002-01-17 08:33:39
--- 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!! ;-)
>
>
> > 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!
regards,
alexander.