Re: Custom Storage Pool questions

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2021-09-19 14:41, Dmitry A. Kazakov wrote:
> On 2021-09-19 12:36, Niklas Holsti wrote:
>> On 2021-09-18 19:19, Dmitry A. Kazakov wrote:
>>> On 2021-09-18 17:59, Niklas Holsti wrote:
>>>
>>>> So you want a way to specify that for a given access type, although 
>>>> the accessed object type has a Finalize operation or needs 
>>>> finalization, the objects left over in the (at least conceptually) 
>>>> associated collection should _not_ be finalized when the scope of 
>>>> the access type is left?
>>>
>>> Exactly, especially because these objects are not deallocated, as you 
>>> say they are left over. If they wanted GC they should do that. If 
>>> they do not, then they should keep their hands off the objects 
>>> maintained by the programmer.
>>>
>>>> To me it seems a risky think to do, subverting the normal semantics 
>>>> of initialization and finalization.
>>>
>>> Quite the opposite, it is the collection rule that subverts semantics 
>>> because objects are not freed, yet mangled.
>>
>> Local variables declared in a subprogram are also not explicitly freed 
>> (deallocated), yet they are automatically finalized when the 
>> subprogram returns.
> 
> Local objects are certainly freed. Explicit or not, aggregated or not, 
> is irrelevant.


Objects left over in a local collection may certainly be freed 
automatically, if the implementation has created a local pool for them. 
See ARM 13.11 (2.a): "Alternatively, [the implementation] might choose 
to create a new pool at each accessibility level, which might mean that 
storage is reclaimed for an access type when leaving the appropriate scope."


>> My understanding of Ada semantic principles is that any object that is 
>> initialized should also be finalized.
> 
> IFF deallocated.
> 
> An application that runs continuously will never deallocate, HENCE 
> finalize certain objects.


And I agreed that in this case it could be nice to let the programmer 
specify that keeping collections is not needed.


>> Has this feature of Ada caused you real problems in real applications, 
>> or is it only a point of principle for you?
> 
> 1. It is a massive overhead in both memory and performance terms with no 
> purpose whatsoever. [...]


Have you actually measured or observed that overhead in some application?


> 2. What is worse that a collection is not bound to the pool. It is to an 
> access type, which may have a narrower scope. So the user could declare 
> an unfortunate access type, which would corrupt objects in the pool and 
> the pool designer has no means to prevent that.


So there is a possibility of programmer mistake, leading to unintended 
finalization of those (now inaccessible) objects.

However, your semantic argument (as opposed to the overhead argument) 
seems to be based on an assumption that the objects "left over" in a 
local collection, and which thus are inaccessible, will still, somehow, 
participate in the later execution of the program, which is why you say 
that finalizing those objects would "corrupt" them.

It seems to me that such continued participation is possible only if the 
objects contain tasks or are accessed through some kind of unchecked 
programming. Do you agree?