Re: first sight

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-16 09:41:16

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

You know, I am sort of tired playing clown here.

Perhaps I should just bow out...

regards,
alexander.