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=-0.9 required=3.0 tests=BAYES_00,XPRIO autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!gandalf.srv.welterde.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: Custom Storage Pool questions Date: Thu, 30 Sep 2021 19:04:20 -0500 Organization: JSA Research & Innovation Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Injection-Date: Fri, 1 Oct 2021 00:04:22 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="25473"; 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:62904 List-Id: "Dmitry A. Kazakov" wrote in message news:sj3r92$pla$3@gioia.aioe.org... > On 2021-09-30 02:16, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:sj2008$1cmo$1@gioia.aioe.org... >> ... >>> Random = unrelated to the object's life time. >> >> All objects have to disappear before their type disappears, so the object >> *cannot* live longer than the access type for which it is allocated from. > > The type of the access type /= the type of object. Only access objects > must disappear and they do. ?? There is nothing in a pool except unorganized memory. "Objects" only exist outside of the pool for some access type. There has to be some organizing type, else you would never know where/when things are finalized. >> It's probably a lousy idea to share pool objects (as opposed to pool >> types) >> amongst access types. > > You need these for access discriminants. Those (coextensions) are one of Ada's worst ideas; they have tremendous overhead without any value. Almost everything has to take them into account. Yuck. Access discriminants of existing objects are OK but really don't add anything over a component of an access type. >> If you do have a longer lived pool and a shorter lived access type, you >> will >> end up with a bunch of zombie objects in the pool that cannot be used in >> any >> way (as any access is erroneous). All that can happen is a memory leak. >> Don't do that. > > 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. You need to use the subpool mechanism to make them safe, because otherwise the objects go away before the type (given these sorts of mechanisms generally have some sort of block deallocation). Again, the only thing in a pool is a chunk of raw memory; the object lives elsewhere. Subpools take care of these lifetime issues (for controlled types, no one wanted to try to make that work for tasks). >> OTOH, object destruction happens before the type goes away, and >> finalization >> happens before that. That is the point here. > > See above, these are different objects of different types. The actual > object type is alive and well (unless killed by some collection). And completely irrelevant. Allocated objects can only be deallocated from the same type as they were allocated. So they're zombie after the type goes away. Only use global general access types for allocation, never, ever anything nested. 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). Randy.