[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