Re: [boost] Re: first sight

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.

> http://groups.google.com/groups?as_umsgid=3A65A492.6251AA52%
> 40compaq.com
>
> 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.