|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-17 08:41:38
From: "terekhov" <terekhov_at_[hidden]>
> --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > 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.
During stack unwinding, stopping the cancel exception is mandatory,
otherwise the whole process is going to die. For example a C++ exception may
be on its way up when someone cancels the thread. With a sticky cancellation
(you can't 'uncancel' the thread) the C++ exception will be handled and then
the next cancellation point will throw pthread_cancel_e or whatever.
If someone wants to catch(...) everything and loop forever, it's not our
responsibility to prevent this.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk