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

[Jason Merrill <jason at redhat dot com>]

On 30 Apr 2003 15:55:06 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

>> > One key question that I'm not sure got resolved on the thread was what
>> > happens in this case:
>> > 
>> >    try { 
>> >      // Something that might:
>> >      // (a) result in cancellation.
>> >      // (b) result in a foreign exception being thrown.
>> >      // (c) result in longjmp_unwind being called.
>> >    } catch (...) {
>> >      // There is no "throw;" here to rethrow.
>> >    }
>> > 
>> > Presumably (a) is the same as either (b) or (c).  Which one?
>> 
>> ... I thought (a) was similar to (c) and that the catch 
>> handler here is *not* invoked in either case.

I agree.

> Oh, bummer.  
>
> I thought (a) was going to be similar to (b), not (c).

To me, the (a) condition is much more like the (c) condition.  That was
also the consensus at the ABI committee meetings.  I don't remember anyone
disagreeing that cancellation and longjmp_unwind would use the same code.

> I think the key design goal should be to make correct single-threaded
> code usable in a multi-threaded program, with as little modification as
> possible.

As little as possible, but no less.  :)

> (Rationale: if I have a library, obtained from somewhere, I want to be
> able to use it in my multi-threaded program without having to take it
> apart bit by bit to see if it's safe.)
>
> Nathan Myers and I were just discussing this, and we agreed that running
> the "catch (...)" handlers is the Right Thing -- at least for thread
> cancellation and foreign exceptions.  (I've got less of an opinion about
> longjmp_unwind; the longmp-ness and the unwind-ness are at odds.)
>
> If we don't let "catch (...)" handlers run, we're violating a basic C++
> assumption, with the result that lots of real code will work in a
> single-threaded environment, but suddenly not work in a threaded
> environment.

The problem is that catch(...) is overloaded in C++.  It's used both for
code that wants to write a cleanup inline and rethrow and for code that
wants to trap all exceptions.

For cancellation and longjmp_unwind, we would like to be able to support
the first use, but we cannot support the second.  There is no good answer
to this question, which is why it's fudged in the ABI; basically, the ABI
says that if a compiler is clever enough to distinguish the cases, it can,
but it's not required.

The simple solution is to give up on handling catch(...) at all in forced
unwind situations and tell people that they should use a local object
cleanup instead.

If C++ had try/finally, that would be the obviously correct way to write
the first use.  Unfortunately, it doesn't.

> If the catch-clause chooses not to rethrow the exception, that just
> means this thread isn't going to be cancelled, which could happen from
> an ordinary pthread cancellation handler.

It could, but that would be a bug in the program.  A cancellation request,
when acted on, is defined to be equivalent to pthread_exit, and there is
nothing to suggest that pthread_exit sometimes doesn't actually terminate
the thread.

Jason