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: Fri, 21 Aug 2020 09:08: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:59775 List-Id: 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. > (Of course, you can use a one-size only pool allocation with Janus/Ada, so > long as what you are allocating doesn't have discrimiant-dependent > components. Janus/Ada has informational messages about such components, so > you can do it if you want/need. Probably should have an aspect as well to > force an error if a static size is expected.) > > Note that this is the reason that Ada doesn't support specifying the pool > used by a container. It would not be reasonable to restrict the allocations > in any way, so implementation-dependent pool designs would not work. > >> No, I meant that if you used a pool behind the scenes for local objects >> you could do that task-specific eliminating interlocking. > > Whether that would be worthwhile would depend on how expensive the locking > is. It could be very expensive on a multi-core architecture. 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! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de