[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