[c++-pthreads] Re: FW: RE: Re: I'm Lost

David Abrahams dave at boost-consulting.com
Tue Mar 14 21:45:27 UTC 2006


Jason Merrill <jason at redhat.com> writes:

> David Abrahams wrote:
>> "Meredith, Alisdair" <Alisdair.Meredith at uk.renaultf1.com> writes:
>> In the model I'm proposing, cancellation will be expressed by
>> telling
>> the cancelled thread to throw a specific exception object at the next
>> (or current) cancellation point reached with cancellation enabled.
>> All exceptions are catchable.  Exceptions can be unstoppable, if you
>> write them in a particular way.
>
> Hmm....
>
> extern "C" int printf (const char *, ...);
>
> struct E
> {
>   bool undead;
>   E(): undead (true) { }
>   ~E() { if (undead) throw E(); }

You need to check uncaught_exception before throwing here.  Remember,
it's unspecified how many copies of the exception are made and if a
destructor of an original is executed due to the throwing of a copy,
you'll terminate.  I think that may account for EDG's behavior.

>>> ii/ if cancellation passes through an exception specification, we
>>> call unexpected and abort which pretty much achieves the same
>>> thing
>>
>> No, it doesn't complete stack unwinding, and it might kill the whole
>> process (I'm not sure about that).
>> 
>>> iii/ if cancellation interupts a dtor during regular stack
>>> unwinding, we call terminate which pretty much has the same effect,
>>> so everyone is still happy. 
>>
>> Likewise.
>
> In previous discussions everyone has agreed that cancellation should be 
> disabled during stack unwinding, to avoid this situation.  This could be 
> implemented either by the EH runtime calling pthread_setcancelstate or 
> by the cancellation runtime checking to see if it's safe to throw a la 
> Alexander.

I'm still happy with that.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



More information about the c++-pthreads mailing list