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-Thread: a07f3367d7,4083771199667fd1 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!198.186.194.249.MISMATCH!transit3.readnews.com!news-out.readnews.com!news-xxxfer.readnews.com!panix!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ensuring resource cleanup Date: Mon, 08 Feb 2010 11:18:42 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <87zl3jertf.fsf@mid.deneb.enyo.de> <876367af7w.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1265645909 4591 192.74.137.71 (8 Feb 2010 16:18:29 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 8 Feb 2010 16:18:29 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:yPUzu5u1/Dz/HqS+FuyuaqVoqr8= Xref: g2news1.google.com comp.lang.ada:8988 Date: 2010-02-08T11:18:42-05:00 List-Id: Florian Weimer writes: > * 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); That one says "I promise not to say 'with Ada.Asynchronous_Task_Control'", which is not related to aborts. It is considered obsolescent, because there's now a more general No_Dependence restriction. To get rid of aborts, I think you need both No_Abort_Statements and Max_Asynchronous_Select_Nesting => 0. I believe this will cause the overhead of abort deferral to go away, but to be sure, you should try it. >>>...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. The new implementation of finalization I mentioned avoids those lists. Except that lists are needed in the case of heap-allocated objects, because they need to be finalized when the scope of the access type is left (unless finalized early by Unchecked_Deallocation). C++ does not require that, so is easier to implement, at the cost of possibly missing some finalizations. But anyway, efficient finalization is most important for stack-allocated objects. >> 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. And inefficient, because they used trampolines. GNAT got rid of trampolines except in some corner cases. Note that trampolines will cause your program to crash if DEP is enabled on windows (or the equivalent feature on Linux). There's a restriction for that, too -- search the GNAT docs for "trampoline". - Bob