Re: Custom Storage Pool questions

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

On 2021-09-18 13:22, Dmitry A. Kazakov wrote:
> On 2021-09-18 11:03, Niklas Holsti wrote:
>> On 2021-09-18 10:49, Dmitry A. Kazakov wrote:
>>> On 2021-09-17 23:17, Niklas Holsti wrote:
>>>> On 2021-09-17 23:39, Dmitry A. Kazakov wrote:
>>>>> On 2021-09-17 21:46, Simon Wright wrote:
>>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>>>
>>>>>>> Nope, especially because the issue with X'Address being unusable for
>>>>>>> memory pool developers is a long standing painful problem that 
>>>>>>> need to
>>>>>>> be resolved. That will never happen until a measurable group of 
>>>>>>> people
>>>>>>> start asking questions. So you are doubly welcome.
>>>>>>
>>>>>> There are two attributes that we should all have known about,
>>>>>> Descriptor_Size[1] (bits, introduced in 2011) and 
>>>>>> Finalization_Size[2]
>>>>>> (storage units, I think, introduced in 2017)
>>>>>
>>>>> They are non-standard and have murky semantics I doubt anybody 
>>>>> really cares about.
>>>>>
>>>>> What is needed is the address passed to Deallocate should the 
>>>>> object be freed = the address returned by Allocate. Is that too 
>>>>> much to ask?
>>>>
>>>> That is already required by RM 13.11(21.7/3): "The value of the 
>>>> Storage_Address parameter for a call to Deallocate is the value 
>>>> returned in the Storage_Address parameter of the corresponding 
>>>> successful call to Allocate."
>>>
>>> You missed the discussion totally. It is about X'Address attribute.
>>
>>
>> Sure, I understand that the address returned by Allocate, and passed 
>> to Deallocate, for an object X, is not always X'Address, and that you 
>> would like some means to get the Allocate/Deallocate address from (an 
>> access to) X. But what you stated as not "too much to ask" is 
>> specifically required in the RM paragraph I quoted. Perhaps you meant 
>> to state something else, about X'Address or some other attribute, but 
>> that was not what you wrote.
> 
> I wrote about attributes, specifically GNAT-specific ones used in the 
> blog to calculate the correct address.


You wrote about the attributes in an earlier paragraph, not the one that 
said "too much to ask" -- see the quotes above. But ok, enough said.


> "Too much to ask" was about an 
> attribute that would return the object address directly.
> 
>> Given that an object can be allocated in multiple independent pieces, 
>> it seems unlikely that what you want will be provided.
> 
> Such implementations would automatically disqualify the compiler. 
> Compiler-generated piecewise allocation is OK for the stack, not for 
> user storage pools.


That is your opinion (or need), to which you are entitled, of course, 
but it is not an RM requirement on compilers -- see Randy's posts about 
what Janus/Ada does.


>>>>> BTW, finalization lists (#2) should have been removed from the 
>>>>> language long ago. 
>>>>
>>>> Huh? Where does the RM _require_ finalization lists?
>>>
>>> 7.6.1 (11 1/3)
>>
>>
>> RM (2012) 7.6.1 (11.1/3) says only that objects must be finalized in 
>> reverse order of their creation. 


Oops, I quoted the above from 7.6.1 (11/3), which specifies the order of 
finalization in another case (finalization of a master). RM 7.6.1 
(11.1/3) leaves the order arbitrary for the finalization of a collection.


>> There is no mention of "list".
> 
> It talks about "collection."
> 
>> Then your complaint seems to be about something specified for the 
>> order of finalization, but you haven't said clearly what that 
>> something is.
> 
> No, it is about the overhead of maintaining "collections" associated 
> with an access type in order to call Finalization for all members of the 
> collection.


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? 
Have you proposed this to the ARG?

To me it seems a risky think to do, subverting the normal semantics of 
initialization and finalization. Perhaps it could be motivated for 
library-level collections in programs that are known to never terminate 
(that is, to not need any clean-up when they do stop or are stopped).