Re: __attribute__((cleanup(function)) versus try/finally

[Jason Merrill <jason@redhat.com>]

On 06 May 2003 12:38:09 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

>> In any case, how are you thinking to do this?  You've mentioned such a
>> thing before, but I haven't noticed an implementation sketch.
>
> I did on the gcc list, but it got lost in the noise, I think.  
>
> The strategy is:
>
> (1) Have pthread_cleanup_push include the current $sp in the cleanup
> record.  Otherwise, use the same data structures currently used by
> glibc's pthread_cleanup_push.
>
> (2) When an exception is thrown:
>
> - Figure out where the next handler/cleanup will be.
>
>   (By hypothesis, this is not going to be in C code, because we don't
>   have try/finally in C.)
>
> - If unwinding the stack to that destination will result in $sp be older
> than the $sp recorded in the cleanup at the top of the C cleanup stack,
> run C cleanups until that is no longer true.

> - Transfer control to the handler as is done now.

Hmm, I suppose you can assume that $sp is linear.  I guess that would work,
except that you can't unwind through C unless the C code has unwind info.

If you assume that you won't be trying to unwind through C code without
unwind info into C++ code, this still requires that you handle the
cancellation exception specially.  When you run out of unwind info, rather
than call terminate you need to hand off to the old pthread_exit.

Of course, that could be implemented by setting the terminate_handler field
in the exception header, but then you'd call it in all situations where you
would otherwise call terminate.

And if you need to handle unwinding out to C++ code in some cases, you
might as well always use the same technique.  Regardless of what we do
about C cleanups, any C code which both calls cancellation points and is
called from C++ must have unwind info.  Otherwise we lose the C++ cleanups
(and we can't catch the cancellation exception, as you've been asking for).

In effect, this means that any library code that does I/O must have unwind
info.  At that point, it seems to me that we might as well always emit it,
since it only costs us in disk space.  That's what Tru64 does.  And Irix.
A compromise would be for -pthreads to imply -fexceptions.

>> > The try/finally solution cannot be implemented with this same
>> > performance; it will, in fact, exact a performance price, in terms of
>> > both code space and the speed at which cleanups are run, on all
>> > systems.  On systems with setjmp/longjmp exceptions, both costs will be
>> > very high indeed.

I think you're exaggerating the costs.  This is the way the C++ frontend
works, and you only incur the costs when you use the feature.  The design
philosophy of EH has always been that the speed of the normal code is what
matters, not the cleanups.

>> Hmm.  Are you talking about representing cleanups in the LSDA via a
>> function pointer and a CFA offset for the argument object?  That way you
>> still need unwind info and PC range tables, but you don't put any code into
>> the function itself.
>
> I'm not as sophisticated as you about this; I don't actually know what
> all the EH implementation details are.  With the scheme above, you do
> still need PC range tables and (some?) unwind information, but you don't
> put any code into the function.  I keep mumbling that I think you might
> be able to avoid some of the unwind information for C, but I've never
> done what it would take to prove or disprove that assertion.  

> The key point is that you don't need any handler code in the function.

I'm not sure why that's key.  Exception handlers in the function can be
moved aside to improve cache locality.  I think we already do this.

> The observation behind this is that pthread cleanups -- unlike C++ catch
> clauses -- do not need to execute in the frame of the function that
> pushed them.  They just need to execute while the stack is still there,
> in case the "arg" to the function directly or indirectly references
> stuff on the stack.

No, they don't need to.  Nor do C++ destructors.  But they do anyway.  If
we decide that moving cleanup calls out of line is an important
optimization, doing it via analysis of the cleanup expression would allow
C++ and Java to benefit from it as well.

One major practical problem with attribute(cleanup): It doesn't map very
well onto pthread_cleanup_push.  With attribute(cleanup) the cleanup
argument is the variable to which the attribute is attached, but with
pthread_cleanup_push, the cleanup argument is usually a local variable
which has already been declared, so you need to indirect through another
function.

It seems to me that a lot of your objections come from resistance to
letting EH into C.  But if we want to interleave pthread and C++ cleanups,
we don't have any choice.

Jason