[c++-pthreads] Re: thread-safety definition

[Wil Evers]

Richard Henderson wrote:

> On Fri, Jan 09, 2004 at 07:01:31AM +0100, Wil Evers wrote:
> 
>>A second exception escaping from a destructor called while unwinding
>>the stack because of some earlier exception will result in program
>>termination.
>>
>>If catching (and not rethrowing) this second exception breaks the 
>>cancellation machinery, then it is the cancellation machinery - and not 
>>the program in question - that is broken.  In other words: we need a way 
>>to prevent this scenario.
>  
> It would be trivial to adjust the c++ runtime to disable cancelation
> while exceptions are in flight.  That avoids that scenario entirely.

It obviously does.  But does that imply we don't need 
'catch-and-dont-rethrow' blocks in destructors anymore?  Please consider 
this example:

remote_resource_holder::~remote_resource_holder()
{
   remote_resource->release();
}

Disabling cancellation while exceptions are 'in flight' means we can't 
run into a double fault because of a cancellation request detected in 
remote_resource->release() while unwinding on behalf of some previously 
raised exception.  However, we may also be unwinding on behalf of some 
previously detected cancellation request, and it that case, a networking 
exception thrown from within remote_resource->release() *will* cause the 
program to terminate.

Please note that this problem is not caused by the use of exceptions for 
handling cancellation; any other previously raised exception could lead 
   to the same disaster scenario - which is why thinking about 
cancellation as some special kind of exception is unsufficient.

Instead, this example serves to show how dangerous it is to let 
exceptions escape from destructors.  Especially when we don't now which 
exceptions may be thrown from remote_resource->release(), about the only 
reasonable implementation of this destructor is:

remote_resource_holder::~remote_resource_holder()
{
   try {
     remote_resource->release();
   } catch (...) {
     // We may try to log what happened,
     // but can't let the exception escape!
   }
}

I've noticed that some people on this list object to this design, but so 
far, I haven't seen an alternative.  In other words, I think we should 
be prepared for threads that discard cancellation exceptions - which is 
why Nathan's 'sticky cancellation' makes sense to me.

- Wil