From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!194.134.4.91.MISMATCH!news2.euro.net!newsfeed.freenet.ag!newsfeed.freenet.de!news.tu-darmstadt.de!news.belwue.de!LF.net!news.enyo.de!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: Ensuring resource cleanup
Date: Mon, 08 Feb 2010 17:01:55 +0100
Message-ID: <876367af7w.fsf@mid.deneb.enyo.de>
References: <87zl3jertf.fsf@mid.deneb.enyo.de>
	<wccmxzjkalz.fsf@shell01.TheWorld.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: idssi.enyo.de 1265644915 621 212.9.189.177 (8 Feb 2010 16:01:55 GMT)
X-Complaints-To: news@enyo.de
Cancel-Lock: sha1:q68UsmA/sb6m3KWZcieVAEcKtfY=
Xref: g2news1.google.com comp.lang.ada:8985
Date: 2010-02-08T17:01:55+01:00
List-Id: <comp.lang.ada>

* Robert A. Duff:

>> (because of the tag and because the finalizer is abort-deferred, ...
>
> I think if you use the appropriate pragma Restrictions, so the
> compiler knows there are no aborts, it will avoid the cost
> of deferring and undeferring aborts (which is quite high
> on some systems).

What is the appropriate pragma?  This doesn't seem to have an effect:

pragma Restrictions (No_Asynchronous_Control);

>>...which
>> seemed to defeat inlining
>
> Inlining of what?  The Initialize and Finalize calls?

Most of the benefit of inlining them, because there are multiple
subprogram calls involved, including indirect ones.  I doubt GCC
treats them as intrinsics, so they interfere with register allocation
etc.  GCC doesn't seem to be able to devirtualize the implicit call to
Finalize, either.

I don't understand why GNAT needs to maintain a separate finalization
list, either.  C++ use regular exception handling for this task.

> You could wrap this is a procedure:
>
>     procedure With_Cleanup (Action : not null access procedure (...));
>
> so you only have to write the above pattern once (per type that needs
> cleanup), and you can call it with any Action procedure you like.

Yes, I need to try that.  Back when the original code was written,
anonymous access-to-subprogram types were still rather buggy.