Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-16 10:20:24


--- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> --- 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.
>
> http://groups.google.com/groups?as_umsgid=3A65A492.6251AA52%
> 40compaq.com
>
> David Butenhof wrote:
>
> "Cancel just posts a pending cancel. Once the cancellation unwind
> starts,
> cancelability is disabled for the duration. Therefore, either
you're
> just re-posting the pending cancel (which does nothing) or posting
a
> pending cancel on a thread that should have cancelability disabled
> (which does nothing). Sure, it's legal, but not very interesting.
>
> There is an exception, because a cleanup handler has no API
> restrictions, and could enable cancelability. What would happen
after
> that is somewhat undefined, but it's technically legal. So a second
> cancel (or even a third) while the thread was already unwinding
> MIGHT do
> SOMETHING. No portable application would ever do this, though, so I
> don't see any point to spending much time worrying about it."

I'm not sure this really applies to what was said. Different schemes
for implementing cancellation, after all. In POSIX you can't pre-
empt a cancellation request that was "accepted" by a thread, so Mr.
Butenhof is quite correct that repeated calls to cancel are
meaningless. However, we're not talking about repeated calls, only
about a "sticky" flag that indicates a cancellation request on the
thread was made.

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

I really don't think you should. Most of what you've had to say has
been beneficial. I think that sometimes you're too stuck on POSIX
and not willing enough to try and envision how things should be for a
language that POSIX truly doesn't cover, but your knowledge of POSIX
is still invaluable. It is, after all, the only _standard_ threading
library available, and as a standard many issues were addressed that
many of us, no matter how experienced, can even envision.

So, please, don't bow out.

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk