From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Comprehending subpools Date: Fri, 15 Jun 2018 17:15:21 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Fri, 15 Jun 2018 22:15:22 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="14219"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:53131 Date: 2018-06-15T17:15:21-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:pfvp1k$ph4$1@gioia.aioe.org... > On 2018-06-14 23:21, Randy Brukardt wrote: > >> The use case is situations when you have separable data structures that >> it >> only makes sense to treat as a whole. Think of an expression tree in a >> compiler. There are a lot of inter-structure links, so a reference >> counting >> scheme for every pointer doesn't work. Rather, you can use a subpool and >> only reference count the references to the entire tree. When that goes to >> zero, you use the subpool to clobber the entire structure. Alternatively, >> you might have weak references to the tree, that automatically get nulled >> when the tree is clobbered. > > I think the questions rather were: > > 1. What is so special about arena or a mark-and-release pool that it > cannot be handled by a user-defined pool in Ada 95? No pool that does block deallocation (not using Unchecked_Deallocation) can work properly with controlled objects. For almost all implementations, attempting to do that with controlled objects would cause the program to instantly crash because of an attempt to follow pointers that no longer exist. Since virtually all memory management schemes in Ada use controlled types or some language-defined equivalent, that essentially means that you would be so limited in what you can put into such a pool that it is close to useless. > 2. Arena is inherently unsafe whatever implementation used. So all talk > about "safety" does not make much sense. "Safety" in this case is related to properly handling controlled types. With that, one can construct properly working strong and weak references and other safe memory management structures that will work on essentially any Ada objects. Without it, you have no chance of any safe memory management. The basic idea is that one manages the "strong" references to an arena (such as the reference to the root of a tree), and when they are all gone, one can safety destroy the arena. The weak references aren't managed for that purpose, but don't become erroneous when the arena is destroyed, but rather just get (effectively) nulled out. One could implement the containers this way, such that when a container is destroyed, that the entire arena of nodes is immediately reclaimed. (There's no legal references into the container at that point.) In any case, a subpool by itself doesn't provide any safety; it's just a building block to be used to provide such safety. All of the other things needed to build such abstractions already existed in Ada, the only thing missing was an ability to finalize all of the objects in an arena (subpool) at once. Draw your own conclusions as to how valuable (or not) that is. Randy.