catch(...) and forced unwind

[Matt Austern]

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.  POSIX requires a number of
functions (such as read, write, open, and close) to be cancellation
points, and allows but does not require a number of others (such as
fread, fwrite, and putc).

Deferred cancallation is scary enough, because it means that
most interesting C library functions or system calls may be cancellation
points.  Asynchronous cancellation is *really* scary: it means that
literally anything may be a cancellation point, that you can get thread
cancellation even in a tight loop that does nothing but arithmetic.  
That's
why David Butenhof thinks that using asynchronous cancellation is
nearly always a mistake, and why I'm inclined to agree with him.

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.

			--Matt