Re: Interleaving pthread_cleanups in C and C++

[Zack Weinberg <zack at codesourcery dot com>]

Daniel Jacobowitz <drow@mvista.com> writes:

> On Mon, May 05, 2003 at 08:10:56PM -0300, Alexandre Oliva wrote:
>> On May  5, 2003, Mark Mitchell <mark@codesourcery.com> wrote:
>> 
>> >> Perhaps even
>> >> 
>> >> #define pthread_cleanup_push(H, A) \
>> >> { struct __pthread_cleanup __pc = { (H), (A), true } \
>> >> __attribute__((cleanup (__pthread_cleanup_routine)));
>> 
>> > This is a good idea.
>> 
>> The only thing I find sad about this is that it doesn't seem to enable
>> one to define __try and __finally as macros with the expected
>> behavior, such that, when __try/__finally make it to the standards,
>> and/or people realize it was a mistake to not put it in in the first
>> place, it's easy to rearrange code to take advantage of this.
>> 
>> I'd much rather introduce a feature that *could* actually be used to
>> implement __try/__finally by means of preprocessor macros.  I'd love
>> to be proved wrong, but I can't see how this proposal would enable
>> this use :-(
>
> I think I don't understand the logic which permits
> __attribute__((cleanup)) but not try/finally.  The primary difference
> is that the attribute uses a nonstandard syntax which we already have
> instead of introducing a new one (which other vendors have). 
> Conceptually, they exercise the same behavior, except that the cleanup
> is restricted to being a function call instead of living in the local
> scope.

With my language designer hat on, I would like to see both.  I think
that, although semantically equivalent, there are some things for
which one is a better notation and some things for which the other is
a better notation.

I also happen to think that pthread_cleanup_push/pop are one of the
things that are better expressed with attribute cleanup / C++
destructor notation.

Now, with my GCC maintainer hat on, this conversation is about
something which is intended to squeak into 3.3.0 or else be put on the
branch immediately after 3.3.0 ships.  Namely, support for NPTL's
cleanups-as-exceptions model.  I do not think this is an appropriate
context to talk about introducing new nonstandard syntax, even if
other vendors do have it.  Especially with the fragility of the C
parser.  Extending an existing nonstandard notation (attribute) can be
done with much lower risk.

This is my last word on the subject.  Please stop cc:ing me on the thread.

zw