Re: first sight

From: Tom Becker (voidampersand_at_[hidden])
Date: 2002-01-17 04:20:03

On Wed, 16 Jan 2002 23:43:27 -0000, "bill_kempf" 
<williamkempf_at_[hidden]> wrote:
>So, all this discussion leads us to:
>
>1) Use deferred cancellation (and allow the user to turn cancellation
>off).
>2) Use a C++ exception for cancellation.
>3) Allow the user to catch the exception.
>4) Allow the user to "eat" the exception.
>5) Make the cancellation "flag" a sticky flag, so if the user "eats"
>the exception it will eventually be re-thrown when they call another
>cancellation point.
>6) Ensure cancellation points don't throw when uncaught_exception()
>returns true.
>7) Document that in general one should always rethrow a caught
>cancelation exception.

This works for me.

Maybe 3) and 4) could be worded as "not prevent" rather than "allow".

Doing a quick check on uncaught_exception(), Herb Sutter doesn't like 
it, but this particular use of it seems like the exception to the 
rule. Also, it's not supported on all platforms, notably MSVC 6.0 
where it's hardwired to always return false. However, it seems 
essential for allowing cancellation points in destructors. Is there a 
reasonable way to implement cancellation in Boost.Threads so that 
none of the automatic cancellation points are in destructors? It 
would be nice if Boost.Threads can check uncaught_exception() as a 
benefit for the developer, but not depend on it for its own 
implementation.

Thanks!

   Tom

-- 
Tom Becker                      "Within C++, there is a much smaller and
<voidampersand_at_[hidden]>        cleaner language struggling to get out."
                                                       -- Bjarne Stroustrup