From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-2.9 required=3.0 tests=BAYES_00,NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Sat, 18 Sep 2021 12:03:03 +0300 Organization: Tidorum Ltd Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net JAxbmNcDJEjdYtIJpqNqoA1FI9GbqNf4TQybOTVPuNhXba8D0L Cancel-Lock: sha1:3OiIBZJNN4Zm3k+AAAJEGHi6R3g= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:62772 List-Id: 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" 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.