Re: first sight

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