[cxx-abi-dev] gcc unwind ABI change for forced unwind

[Jason Merrill]

On Thu, 22 May 2003 11:40:47 -0700, Cary Coutant <cary at cup.hp.com> wrote:

>> Personally, I dislike the attempt to separate "cleanup" from
>> "finalization" (handle/catch). I don't like the idea of an exception that
>> can't be finalized, because it reduces the application's ability to
>> control behavior.
>
> I didn't mean to imply that I liked this either, but it seemed a useful
> compromise given the unlikelihood that C++ will ever add try/finally.

Dave, did you see the mail where I mentioned the compromise I came up with?
gcc will now run all catch(...) blocks during forced unwind, but if we exit
the block other than by rethrow, we try to destroy the exception, which
calls terminate.

> I'm still not entirely comfortable with the idea of thread cancellation
> (and other forced unwinds) being a normal (catchable) C++ exception

I don't think we should lump cancellation with longjmp_unwind in this
discussion.  I don't think anyone has suggested that one should be able to
catch and discard a longjmp_unwind exception (well, before Dave just now).
A longjmp is an explicit transfer of control; IMO nothing should be able to
block it.

There is, however, an argument that cancellation is a weaker condition, and
if an application wants to discard the exception and defer the thread exit
for a while, that's its perogative.  In other words, cancellation shouldn't
use forced unwind.  Note that Ulrich Drepper, who recently rewrote the
glibc pthread library, thinks that this would violate pthread semantics.

> but if consensus has been reached outside this list, and those on this
> list generally agree, I don't want to drag the discussion out any more.

AFAIK there is no consensus.

> What changes are needed in the C++ ABI document? Do we need to add anything
> in the base (C) ABI to cover thread cancellation and exit so that cleanups
> can be properly interleaved?

I think changes are needed.

Jason