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!aioe.org!.POSTED.2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Proposal: Auto-allocation of Indefinite Objects Date: Sun, 23 Aug 2020 14:28:46 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> NNTP-Posting-Host: 2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:59788 List-Id: On 23/08/2020 07:03, Randy Brukardt wrote: > "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. Yes, and this is why light-weight implementations are important. You want to take them away while giving no promises, no, actually promising that expecting the alternative to work would be: "an unrealistic expectation." (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de