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

[Wil Evers]

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?

A reasonable thing to do would be to disable cancellation by default 
(using pthread_setcancelstate()), and to selectively enable cancellation 
  in sections of code that were written with cancellation in mind. 
RAII-like objects could be used to ensure the thread's cancellation 
state is restored on all exits from a block, both exceptional and 
non-exceptional.

An interesting side-effect of this approach is that once it is in place, 
there is no reason for the system's cancellation machinery to manipulate 
a thread's cancellation state at all; it could be managed exclusively 
from user code.  In addition to protecting sections of code from 
unexpected cancellation exceptions, it could also be used to *enable* 
cancellation in sections that would otherwise be run with 
system-disabled cancellation.

- Wil