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

[Wil Evers]

Peter Dimov wrote:

> 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.

Exactly.  However, there are (under model #1) significant differences 
between the example above and the code that would result if we removed 
the cancellation managers.

My objection to model #1 (and, to some extent, #2 as well) is that is 
breaks some commonly used assumptions such as 'destructors do not throw' 
(#1) or 'system calls do not throw' (#1 and #2).  Implicitly disabling 
cancellation during stack unwinding solves some of the problems that are 
introduced by mapping cancellation requests to C++ exceptions, but not 
all of them.

It seems to me that a complete solution compatible with #1 - one that 
preserves existing semantics, except for the places where we are know we 
are able to deal with cancellation exceptions - requires the use of an 
idiom like the one I tried to illustrate above.  And - I'm repeating 
myself here - once the user has put all this in place, there is no need 
for the cancellation machinery to implicitly disable cancellation at 
all.  It makes no difference any more - just as you observed.

> 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.

Let's add (3): the program will terminate if (1) occurs while the stack 
is already unwinding.  Highly undesirable too, so clearly, something 
must be done to prevent all of this.  What I'm trying to do is present 
an alternative to the IMO incomplete solution #1 provides.

- Wil