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

Meredith, Alisdair Alisdair.Meredith at uk.renaultf1.com
Wed Mar 8 23:26:18 UTC 2006


Sorry to be dense, or if I am covering old ground - just confirming I understand correctly:
Also sorry for HTML format - it is all I can get remotely from our Exchange server :¬(
 
i/  cancellation will propogate as an (uncatchable?) exception, implying stack unwinding.
ii/ if cancellation passes through an exception specification, we call unexpected and abort which pretty much achieves the same thing
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.
 
I am still not sure about:
iv/ if an exception is thrown but not caught in main, it is implementation defined whether stack unwinding occurs, so it will really be implementation defined whether the stack is unwound for thread cancellation in this scheme.
 
I am also not clear whether unexpected / terminate will kill just the thread, or the whole process.  I am currently expecting the latter as the status quo, although not with a strong opinion to fight for <g>
 
AlisdairM

________________________________

From: Mark Mitchell [mailto:mark at codesourcery.com]
Sent: Wed 08/03/2006 23:15
To: Jason Merrill
Cc: Wil Evers; David Abrahams; c++-pthreads at codesourcery.com
Subject: Re: [c++-pthreads] Re: FW: RE: Re: I'm Lost



Jason Merrill wrote:

> If you can interrupt cancellation, re-cancellation is implemented
> trivially simply by just having the cancellation exception destructor
> call 'pthread_cancel (pthread_self ())'.  The sticking point is being
> able to abort the cancellation in the first place, which is what Uli has
> been opposed to.

It sounds like we really are close to a solution then; I think everyone
here would be happy with the re-cancellation thing, and the destructor
trick means that there's really no way the thread can permanently
discard the cancellation request, short of things like longjmp -- and,
of course, if the thread is really determined not to go away it can just
hang around anyhow.  So, it seems like this ought to satisfy everyone
from the user-level perspective.

> I don't think he's opposed to catching it, just to doing anything that
> would involve backing out of the cancellation once it's started.

Would the above satisfy him?

--
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713


---------------------------------------------------------------------

For further information on Renault F1 visit our web site at www.renaultf1.com. 

WARNING: please ensure that you have adequate virus protection in place before you open or detach any documents attached to this email.

This e-mail may constitute privileged information. If you are not the intended recipient, you have received this confidential email and any attachments transmitted with it in error and you must not disclose, copy, circulate or in any other way use or rely on this information.

E-mails to and from the Renault F1 Team are monitored for operational reasons and in accordance with lawful business practices.

The contents of this email are those of the individual and do not necessarily represent the views of the company.

Please note that this e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium. We advise that you understand and observe this lack of security when e-mailing us.

If you have received this email in error please forward to: is.helpdesk at uk.renaultf1.com quoting the sender, then delete the message and any attached documents
---------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/c++-pthreads/attachments/20060308/9763e2bc/attachment.html>


More information about the c++-pthreads mailing list