Re: [c++-pthreads] Re: thread-safety definition
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [c++-pthreads] Re: thread-safety definition
- To: Richard Henderson <rth@xxxxxxxxxx>
- Subject: Re: [c++-pthreads] Re: thread-safety definition
- From: Wil Evers <wil@xxxxxxxxxxxxxx>
- Date: Sat, 10 Jan 2004 22:19:41 +0100
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