[c++-pthreads] Re: pthread_cancel and EH: let's try this again

[Gabriel Dos Reis]

Wil Evers <wil at bogo.xs4all.nl> writes:

| Mark Mitchell wrote:
| 
| > It's not NPTL that says something about "catch (...)" -- it's C++
| > that says that.
| > The whole point of destructors and exceptions in C++ is that you are
| > guaranteed that all exits from a block will result in a particular
| > set of cleanup code -- including both destructors and the bodies of
| > catch clauses -- being run in a particular order.
| > Jason's proposal #2 splits two things which are considered
| > equivalent by programmers (destructors and catch clauses) into
| > distinct classes, running some but not the other.  That's not in the
| > spirit of C++, IMO.  As Nathan has demonstrated, there are cases
| > where you *must* use a catch clause to manage cleanups.
| 
| I agree, but please note that the handling of catch (...) blocks is
| not the only distinction between model #1 and model #2.
| 
| In model #2, cancellation is disabled in all destructors; in model #1,
| cancellation is only disabled when destructors are called while
| unwinding the stack.
| 
| In other words, #2 has the desirable property that it does not break
| existing code that assumes destructors *never* throw. I suspect that a
| lot of code relies on that assumption, and I know for sure that
| practically all of my code does.
| 
| Supposing model #1 is accepted, then how do we cope with existing code
| that assumes destructors never throw, or, more generally, with code
| that was not written to deal with exceptions thrown from cancellation
| points?

Destructors that throw usually lead to brittle codes.  The
problems are with those destructors, not with the cancellation model
implemented for C++. The destructors should be fixed, because that
problem is independent of multithreading.

-- Gaby