Re: Interleaving pthread_cleanups in C and C++

[Richard Henderson <rth at redhat dot com>]

On Sat, May 03, 2003 at 06:08:09PM -0700, Mark Mitchell wrote:
> (1) pthread cancellation should be just an ordinary exception -- not
>     "forced unwinding".  That should be reserved for longjmp_unwind.
[...]
> I think (1) is the clear consensus position among the C++ people who
> have commented.

Now that we've allowed catch-all handlers to trigger, I don't
believe you can tell the difference, so I don't see what it
really matters.

> (2) Any exception passing through C code should run pthread_cleanup_push
>     cleanups.
[...]
> As for (2), these cleanups would otherwise never be run, which seems
> wrong.  The semantics of pthread_cleanup_push are that the cleanup is
> run when the frame is exited, and exceptions are just another way to do
> that.

Granted.

> The reason my scheme is better than try-finally in C is that it doesn't
> require a language extension.  (And, I think it is even possible to get
> away without unwind tables for C code on many systems, since you do not
> have to actually unwind the stack.  But I need to think that through a
> little further.)

First, I very much dislike intertwining libc internals into libgcc
in this fashion.  I don't think I can stress this enough.

Second, while you don't need unwind info for C only, you DO need it
for mixed C and C++, which is the only time you're going to care
about whether exceptions run C cleanups.  The reason is that if you
can't unwind the stack, you can't find the next C++ frame, which means
that you won't find the next C++ frame's catch handler.

Third, the C sjlj has quite a bit of overhead preparing for the
exception even when it does not occur.  The libc people complain
about this every so often.  A pure libunwind solution with try/finally
would have no such setup overhead.


r~