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

[Wil Evers]

Ted Baker wrote:

>>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.
> 
> 
> There is no real problem here. 
> 
> 1) Yes, you want to be able to catch all *local* exceptions, and
> not rethrow them, in destructors and cancellation cleanup routines.
> 
> If you disable cancellation during the execution of such routines
> you will never have a cancellation exception that would be caught
> by the "catch" of your destructor example above.
> 
> 2) This does not mean you can't disable the *generation* of a (new)
> cancellation exception during execution of such a destructor or
> cleanup routine.
> 
> 3) This does not mean you will lose an old cancellation exception,
> if that is what caused you to execute the destructor or cleanup
> routine.  On return from this routine, execution will continue
> along the path that took you into this routine, i.e., the
> processing of the old cancellation exception.
> 
> 4) This does not mean you will lose a new cancellation exception, if
> you were executing the destructor or cleanup routine for some other
> reason. Whenever you next get to a point where cancellation is
> enabled again, the cancellation processing will begin.
> 
> It does mean that you need to be able to keep track of nested
> cancellation-disabled sections, so that you can disable
> cancellation during the entire exception processing sequence, up
> until you are in the "catch", and you can *also* (nestedly)
> disable cancellation during destructors.

Please note that the example destructor above is also called on a 
regular (non-exceptional) exit from the block in which the 
remote_resource_holder lives.

Since, in that case, there is no exception 'in flight', a cancellation 
exception thrown from remote_source->release() *will* be discarded, 
unless - in *all* such destructors - the code is changed to explictly 
disable cancellation.

In other words, non-sticky cancellation will break existing code, and 
the replacement code will not be pretty.  IMHO, this is highly 
undesirable - writing robust destructors is hard enough without these 
complications.

- Wil