Re: Custom Storage Pool questions

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

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.

Given that an object can be allocated in multiple independent pieces, it 
seems unlikely that what you want will be provided. You would need some 
way of iterating over all the pieces allocated for a given object, or 
some way of defining a "main" or "prime" piece and a means to get the 
Allocate/Deallocate address for that piece.


>>> 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. There is no mention of "list".


>> I see them mentioned here and there as a _possible_ implementation 
>> technique, and an alternative "PC-map" technique is described in RM 
>> 7.6.1 (24.r .. 24.t).
> 
> I don't care about techniques to implement meaningless stuff. It should 
> be out, at least there must be a representation aspect for turning this 
> mess off.


Then your complaint seems to be about something specified for the order 
of finalization, but you haven't said clearly what that something is.