[c++-pthreads] Restating the Jason model

Wil Evers wil at bogo.xs4all.nl
Tue Jan 13 15:29:18 UTC 2004


Dave Butenhof wrote:

> Wil Evers wrote:
> 
>> Jason Merrill wrote:
>>
>>>  * Should cancellation also be disabled in destructors run during normal
>>>    execution?  In catch blocks?
>>>
>>> IMO, no and no.
>>
>> This implies a difference in how destructors behave, depending on why 
>> they are invoked.  If such a difference can be avoided, I think it 
>> should be: we have Ted Baker's model (destructors always disable 
>> cancellation), and the other obvious choice is to leave it to the user 
>> to take the necessary precautions when writing destructors. Good C++ 
>> programmers already know how to do that. 
> 
> They may know how, but most haven't previously had any need to worry 
> about that. It seems to be fairly widely agreed here that propagating an 
> exception out of a destructor is "bad". Since that's what will happen if 
> cancellation strikes an unprepared destructor, it seems to me that the 
> best option is to prevent that in the default case (by disabling 
> cancellation), and requiring any destructor that really WANTS to be 
> cancellable to do something unusual.

IMO, the problem with Jason's model is that it only protects against 
*some* cases where exceptions escape from destructors:

* Jason wrote that cancellation will not be disabled when a destructor 
is run during normal (non-unwinding) execution.  In that case - likely 
the most common one - a cancellation exception may be thrown, and will 
escape.

* Many cancellation points are I/O primitives, and I/O operations are 
sources of runtime errors; many C++ libraries report such errors by 
throwing exceptions.  In other words: if we can expect a cancellation 
exception, we should probably expect other kinds of exceptions too. 
Obviously, these exceptions will also escape.

So again, if we're determined not to let exceptions escape, we need a 
catch-and-finalize block.  It seems to me that automatically disabling 
cancellation while unwinding may result in a false sense of security.

- Wil




More information about the c++-pthreads mailing list