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 18:59:27 +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 CnPjrFPgiw4ump0aZOo6NQcRgdpSDRTuBGjP5Q2BUxARpCmcNm Cancel-Lock: sha1:AOmmoO7XgdNZxz9rJPVTOgS/hTw= 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:62775 List-Id: 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" 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).