Re: [RFC] C++ vs forced unwinding

["Mark Mitchell" <mark at codesourcery dot com>]

----- Original Message -----
From: "Jason Merrill" <jason at redhat dot com>
To: "Benjamin Kosnik" <bkoz at redhat dot com>
Cc: "Richard Henderson" <rth at twiddle dot net>; <mark at codesourcery dot com>;
<gcc-patches at gcc dot gnu dot org>
Sent: Wednesday, April 02, 2003 11:40 AM
Subject: Re: [RFC] C++ vs forced unwinding


> On Wed, 2 Apr 2003 09:56:54 -0600, Benjamin Kosnik <bkoz at redhat dot com>
wrote:
>
> > I think the cancellation point stuff should be done orthogonally to
> > exceptions, at least as described to the end-user. Trying to make C++
> > exception specifications fit into what you describe as
> > "not-an-exception" is not going to work, unless you come up with
> > specific extension C++ syntax that means "don't even throw what RTH is
> > calling a "not-an-exception."
> >
> > As it stands, throw() means no exceptions are thrown, ie no throw(*)
> > statements in the codepath. It says nothing about the the synthetic
> > throwing of implicit cleanups.
>
> I don't think you can state that as a fact.  The C++ standard has so far
> carefully avoided saying anything about thread semantics.  It remains for
> us, designing this extension, to decide how this new functionality
> interoperates with the base language.  I'm willing to concede the point,
> but it's a question of design, not careful reading.

I agree.

FWIW, I don't think "throw ()" should have any affect here.  Cancelling a
thread is not throwing an exception, implementation similarities aside.
It's more like "kill -TERM" running SIGTERM handlers.  I think cleanups
should indeed get run in that case, if we're going to run them at all for
thread cancellation, which does seem to make sense.

The other option would be to have people explicitly register a call to
longjmp_unwind as a thread-cancellation function.  Then, there's no
*implicit* unwind, but if you want it it's easy to arrange.  That doesn't
affect whether or not C libraries have to be compiled with -fexceptions.

-- Mark