Re: [boost] Re: first sight

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-16 11:08:34

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, January 16, 2002 10:52 AM
Subject: Re: [boost] Re: first sight

> 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.

As I read Tom's post, that's exactly the point he was making.