Re: Ensuring resource cleanup

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Florian Weimer <fw@deneb.enyo.de> 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