catch(...) and forced unwind

[David Abrahams]

Matt Austern <austern@apple.com> writes:

> On Dec 16, 2003, at 4:23 AM, David Abrahams wrote:
>
>> Yes, though not directly.  Bill Kempf (the Boost.Threads guy)
>> communicated with him and extensively read his writings on the subject
>> before he vaporized.  My understanding, from everything I've read, is
>> that David Butenhof believes that *any* asynchronous (forced, not
>> under user control) cancellation model is wrong.
>
> It's quite true that he thinks asynchronous cancellation is
> hard/impossible to use reliably.  You can see that in sectiom 5.3.2
> of his very clearly written book.
>
> But we aren't talking about asynchronous cancellation.  We're talking
> about deferred cancellation, which means that the thread may be
> cancelled at any cancellation point.  

I'm sorry, I was using a shorthand.  Let me be clear: a cancellation
exception which propagates from a function which is specified not to
throw is the "moral equivalent" of an async exception.  The reason
async exceptions are hard/impossible to use reliably is that
exceptions crop up in regions of code that would normally be nothrow.

> Note that it's possible to temporarily disable thread cancellation in
> critical regions of code.  It might be appropriate for glibc and/or
> libstdc++ to do that.  On the other hand, we'll have to think carefully
> about standard conformance if we do something like that.

Yeah, that idiom is, again, a library-killer.  It requires portable
library authors to be aware of pthreads and insert disablers.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com