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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!x6YkKUCkj2qHLwbKnVEeag.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Sat, 2 Oct 2021 12:18:19 +0200 Organization: Aioe.org NNTP Server 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 Injection-Info: gioia.aioe.org; logging-data="62329"; posting-host="x6YkKUCkj2qHLwbKnVEeag.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:62924 List-Id: On 2021-10-02 11:06, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:sj6gmg$1n1n$1@gioia.aioe.org... >> On 2021-10-01 02:04, Randy Brukardt wrote: > ... >>>> Nope, this is exactly how it works with most specialized pools, like >>>> arenas, stacks, reference counting pools etc. >>> >>> These things don't work as pools in Ada. >> >> Yes, they normally have Deallocate as a void operation or raise an >> exception. > > No, they don't, because they don't work with controlled types, tasks, etc. Of course they do. E.g. with void Deallocation. When an instance of Unchecked_Deallocation is called, the object gets properly finalized, while the memory stays occupied in the pool until all arena is cleared. In the case of reference counted objects finalization is done using an instance Unchecked_Deallocation. Subpools are totally useless there. If necessary, I use a fake pool to run Unchecked_Deallocation on it without reclaiming any memory from the original pool. >>> You need to use the subpool >>> mechanism to make them safe, >> >> I do not see how that could change anything without destroying the whole >> purpose of such pools, namely nearly zero-cost allocation and >> deallocation. > > It ties any finalization to the subpool, so all of the contained objects get > finalized when the subpool is freed. Yes, and there is no need doing that in most practical scenarios. Note also that subpool allocations need to be handled in the user code. It is highly undesirable and error-prone. So, whatever safety you might get from subpool's bookkeeping, you lose it at that point. > ... >>> because otherwise the objects go away before >>> the type (given these sorts of mechanisms generally have some sort of >>> block >>> deallocation). >> >> If controlled types need to be used, which rarely happens, a bookkeeping >> is added to finalize them. Instead of IMO useless subpools, one could add >> some allocation bookkeeping support etc. > > That's again not safe in any sense. You shouldn't need to worry about > whether some abstraction that you use uses finalization, especially as you > can't know if someone adds it later. Why compiler assisted bookkeeping is safe for subpools, but unsafe as a stand-alone mechanism? > ... >>> Indeed, I now believe that any nested access type is evil and mainly is >>> useful to cause nasty cases for compilers. I'd ban them in an Ada-like >>> language (that would also simplify accessibility greatly). >> >> See where collections have led you! (:-)) > > No, that's mostly because of accessibility. I'd be happy if one banned doing > any allocations with general access types (mixing global/stack allocated > objects and allocated objects is pure evil IMHO), but that would be rather > hard to enforce. Yes, but there is an alternative option of fixing Unchecked_Deallocation through general access types. > Note that nested tagged types also cause many implementation problems, > adding a lot of unnecessary overhead. Sure, but again. there is a paramount use case that requires dynamic elaboration of tagged types, i.e. the relocatable libraries. You cannot ban them and you cannot forbid tagged extensions declared in a relocatable library. So getting rid of nesting tagged types will ease nothing. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de