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

[Peter Dimov]

Wil Evers wrote:

> It seems to me you may have missed the point I was trying to make at
> the end of my previous message, which is that it seems feasible - or
> even desirable - to use a model in which the cancellation machinery
> doesn't implicitly disable cancellation at all, not even when
> unwinding the stack.  Please consider this example:

[...]

>   void *thread_routine(void *)
>   {
>     cancellation_manager disabler(false);
>     std::ofstream outfile("filename");
>
>     // lots of legacy code...
>
>     outfile << "some output" << std::endl;
>
>     {
>       cancellation_manager enabler(true);
>       some_cancellation_point();
>     }
>
>     // more legacy code...
>
>     return 0;
>   }
>
> I believe the code above is immune to the surprises caused by changing
> ordinary system calls into functions that can throw cancellation
> exceptions.

Whether cancellation is enabled during stack unwinding does not affect your 
example at all.

Leaving cancellation enabled during stack unwinding has the following 
effects:

1. Cancellation points called from destructors or catch+rethrow blocks may 
not complete, but throw;

2. The exception being propagated may be replaced with a cancellation 
exception somewhere along the path.

(1) may or may not be desirable depending on context (it's 75% undesirable 
if you ask me), and I can't imagine a case where (2) would be desirable.

> IMO, not having the cancellation machinery implicitly disable
> cancellation has two distinct advantages:
>
> (*) It provides a clear migration path for existing multi-threaded C++
> code that was not written to expect cancellation exceptions (see
> above).

I think that this migration path is available under all models described so 
far.

> (*) It doesn't impose any particular cancellation handling policy,
> leaving it to the programmer to decide when and how to respond to
> cancellation requests.