From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader01.eternal-september.org!feeder.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: Proposal: Auto-allocation of Indefinite Objects Date: Sun, 23 Aug 2020 00:03:01 -0500 Organization: JSA Research & Innovation Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> Injection-Date: Sun, 23 Aug 2020 05:03:03 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="11355"; 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: reader01.eternal-september.org comp.lang.ada:59785 List-Id: "Dmitry A. Kazakov" wrote in message news:rhnrtu$rk2$1@gioia.aioe.org... > On 21/08/2020 01:25, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:rhmd3c$1eql$1@gioia.aioe.org... >>> On 20/08/2020 02:13, Randy Brukardt wrote: >> ... >>>>> What you do if such an object is allocated via pool-specific access >>>>> type? >>>> >>>> The whole object goes in that pool. The entire mechanism in Janus/Ada >>>> is >>>> built around pools - the stack is represented by a pool object as well >>>> as >>>> various other pools to support the mechanism. >>> >>> OK, but then you are back to the problem that you do not know how that >>> pool works. The user pool might require a certain order of objects >>> inside >>> it and your interference with relocation will break it. >> >> Such a pool does not implement the interface as defined in 13.11. It's OK >> of >> course to write a pool that depends on implementation-specific properties >> (I've done it many times), but such a pool is not usable with portable >> Ada >> code. If the pool allows any sort of allocation at any time, then it will >> work just fine with the Janus/Ada implementation. > > It is a different situation. Such pools are not intended as a general > purpose pools. But the type is. In my view an implementation of the type > provided by compiler must work in all legal cases. Otherwise it is either > language of compiler bug. There's a third possibility: unrealistic expectations. :-) The only kind of pool that is not general-purpose is one that is necessarily depending on the details of the implementation. Trying to constrain what allocations a compiler can do would ensure that a language could not be implemented efficiently or flexibly. That's not a language I'd want to use. ... > It could be very expensive on a multi-core architecture. I suppose, but that architecture would be lousy for running any multi-tasking or parallel program (since any such program is going to need a significant amount of synchronization). A lock-free algorithm is usually the cheapest possible synchronization on any architecture (it usually includes a spin, but the spin is almost never executed). > .. I also think > about scenarios when the object is used inside a protected action. I would > not like to see any pool interaction in an interrupt handler! Interrupt handlers shouldn't be doing anything other than unblocking tasks. I think it is a mistake to allow anything else (as there are always problems with race conditions if you do so). So no heap possibilities as very little is going on. Randy.