Re: Proposal: Auto-allocation of Indefinite Objects

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:rhnrtu$rk2$1@gioia.aioe.org...
> On 21/08/2020 01:25, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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.