Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-16 10:52:39

From: "terekhov" <terekhov_at_[hidden]>

> --- In boost_at_y..., Tom Becker <voidampersand_at_f...> wrote:
> [...]
> > I'm not worried about library code eating thread cancellation
> > exceptions. The library code has to return sometime, and eventually
> > the thread will hit another checkpoint and it can throw another
> > cancellation exception. All the mechanism has to do is not clear
> the
> > appropriate flag until the thread is fully canceled. There is
> little
> > need to force the cancellation exceptions to automatically rethrow
> > themselves. In fact, if I have an application where a fair amount
> of
> > work needs to be done in order to make the thread state safe to
> clean
> > up, being able to stop a cancellation could be a very useful
> feature.
> > I would rather have a simple mechanism that is under developer
> > control, with the concomitant responsibility that my thread code
> has
> > to be reasonably well behaved for it to perform well.

As I understand it, you can't stop a cancellation request. You can only
postpone the cancellation by eating the exception, but when the thread sets
its cancellability back to enabled, the next cancellation point will throw.

> David Butenhof wrote:


> You know, I am sort of tired playing clown here.
> Perhaps I should just bow out...

I'm starting to see your point. Designing a C++ threading library from
scratch without taking into account the considerable experience of the
pthreads committee?

Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at, gregod at, cpdaniel at, john at