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, 29 Jun 2018 14:57:08 -0500 Organization: JSA Research & Innovation Message-ID: References: <351c6acd-8a8c-41a3-bb52-dd3f82322829@googlegroups.com> Injection-Date: Fri, 29 Jun 2018 19:57:09 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="1288"; 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; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:53441 Date: 2018-06-29T14:57:08-05:00 List-Id: wrote in message news:351c6acd-8a8c-41a3-bb52-dd3f82322829@googlegroups.com... ... >I'd rather pull all the nonsense of wrapping access values in controlled >types >out of the client in the first place and put it into the pool itself (a >callback >passed to allocate or something?), instead of just solving the problems >piecemeal. Having to use controlled types for memory management is the >problem IMHO. Let code work with access values directly and leave it to > the pool they came from to decide how and when to clean it up. That was my original idea for what eventually became generalized references. The problem being that the you have to lie about the specification of pools for that to work (the "System.Address" parameters become handles that you pass into a a dereferencor). And magic was required for the call-back needed to tell the pool when the dereference wasn't needed anymore. Most readers couldn't wrap their heads around either part of that. Using a totally different specification for a new kind of pool wasn't appealing, as it would mean having to support multiple ways of doing the same thing. Randy. P.S. The original driving force for subpools came from Tucker Taft and Bob Duff, who had used a system like this when implementing the tool now known as CodePeer. The original proposal was ten times more complicated, containing strong and weak references, and automated deallocation mechanisms. All of these can easily be constructed with the building blocks available, and trying to support all of that would have taken a lot more effort. I've never seen much value for arena memory management myself, but I prefer to hide access types as much as possible with almost no visible surface. In that case, all of the memory management belongs to the objects, and that tends to require separate management for each object.