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: Wed, 29 Sep 2021 19:16:03 -0500 Organization: JSA Research & Innovation Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Injection-Date: Thu, 30 Sep 2021 00:16:04 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="915"; 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:62873 List-Id: "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. Any use of the object after that point is erroneous, so Finalization has to happen before it as well. It's probably a lousy idea to share pool objects (as opposed to pool types) amongst access types. The pool object should have the same lifetime as the access type (we require that for subpools specifically because finalization doesn't make sense any other way). A similar rule should have been enforced for all pools, but it would be incompatible (alas). 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. ... >>> And I suggest doing exactly nothing as opposed to *unsafe*, costly and >>> meaningless behavior mandated by the standard now. >>>> Every object in Ada has a specific declaration point, >>>> initialization point, finalization point, and destruction point. There >>>> are >>>> no exceptions. >>> Yes, and how it that related to the issue? >> Because these are the places that finalization (and >> deallocation/destruction) are defined to happen. > > So? How exactly any of this implies that the place of Finalization can be > in a place other than the place of deallocation? Deallocation is at most a convinience in Ada; it isn't even required to do anything. One never can assume anything is actually recovered, so it is not a meaningful concept semantically. OTOH, object destruction happens before the type goes away, and finalization happens before that. That is the point here. Randy.