Re: [3.3] Followup to C++ forced unwinding

[Mark Mitchell <mark at codesourcery dot com>]

On Wed, 2003-04-30 at 18:02, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Mitchell wrote:
> 
> > You've not explained how falling off the end of a catch handler is
> > impossible, but running a destructor that doesn't return, is possible.
> 
> I did.  The state of the thread changes.  It's not a normal thread
> anymore, it's a terminating thread.  As such it cannot work normally
> anymore, it will behave badly or work not all anymore if used outside
> the cleanup handlers.  It might hang or bring the entire process down.

You still haven't explained what might happen outside the catch-clause
that cannot happen inside the catch-clause or inside a destructor.

> > Skipping over a "catch(...)" block is a bad idea.
> > 
> > Inserting an implicit rethrow is a bad idea.
> 
> I don't see how the latter can be bad.  That's what is supposed to
> happen anyway.

Whether that is supposed to happen or not depends on whether the user
wrote "throw;" in the catch-clause.  It's perfectly reasonable to fall
off the end of catch-clauses; that's one way of saying "try this
operation but keep going if it fails."

> > A compromise position is to call std::terminate for now.
> 
> For all catch blocks or only catch(...)?

I'd be happy either way, in that it would give us time to get this right
before committing to the semantics.

There's no way that we'll ever be able to run code inside a catch clause
other than "catch (...)"; the exception thrown is not of the right type,
so there's no way to bind the handler parameter.  Therefore, I think
that if we're going to unwind the stack, it makes sense to skip over
catch-clauses, other than "catch (...)" clauses.

(It's also vital that cleanups registered with pthread_cleanup_push be
run in LIFO order with respect to C++ destructors and catch-clauses
during stack-unwinding.  That's easy to do if you're going to unwind the
stack (by having the object created by pthread_cleanup_push have a
destructor), but it's not implemented in the version of glibc that comes
with Red Hat 9.)

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC