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!weretis.net!feeder8.news.weretis.net!newsfeed.xs3.de!callisto.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: Custom Storage Pool questions Date: Mon, 20 Sep 2021 19:37:56 -0500 Organization: JSA Research & Innovation Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Injection-Date: Tue, 21 Sep 2021 00:37:57 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="24181"; 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:62797 List-Id: "Dmitry A. Kazakov" wrote in message news:si77kd$rka$1@gioia.aioe.org... ... > 1. It is a massive overhead in both memory and performance terms with no > purpose whatsoever. I fail to see where that sort of thing might be even > marginally useful. The classic example of Finalization is file management on a simple kernel (I use CP/M as the example in my head). CP/M did not try to recover any resources on program exit, it was the programs responsibility to recover them all (or reboot after every run). If you had holes in finalization, you would easily leak files and since you could only open a limited number of them at a time, you could easily make a system non-responsive. You get similar things on some embedded kernels. If you only write programs that live in ROM and never, ever terminate, then you probably have different requirements. Most likely, you shouldn't be using Finalization at all (or at least not putting such object in allocated things). ... > 2. What is worse that a collection is not bound to the pool. It is to an > access type, which may have a narrower scope. So the user could declare an > unfortunate access type, which would corrupt objects in the pool and the > pool designer has no means to prevent that. Pools are extremely low-level things that cannot be safe in any sense of the word. A badly designed pool will corrupt everything. Using a pool with the "wrong" access type generally has to be programmed for (as I answered earlier, if I assume anything about allocations, I check for violations and do something else.) And a pool can be used with many access types; many useful ones are. Some of what you want is provided by the subpool mechanism, but it is even more complex at runtime, so it probably doesn't help you. Randy.