Re: Custom Storage Pool questions

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:sibu1t$12ds$1@gioia.aioe.org...
> On 2021-09-21 02:37, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:si77kd$rka$1@gioia.aioe.org...
>> ...
>>> 1. It is a massive overhead in both memory and performance terms with no
>>> purpose whatsoever. I fail to see where that sort of thing might be even
>>> marginally useful.
>>
>> The classic example of Finalization is file management on a simple kernel 
>> (I
>> use CP/M as the example in my head). CP/M did not try to recover any
>> resources on program exit, it was the programs responsibility to recover
>> them all (or reboot after every run). If you had holes in finalization, 
>> you
>> would easily leak files and since you could only open a limited number of
>> them at a time, you could easily make a system non-responsive.
>
> This is why system resources are handled by the OS rather than by the 
> application. But I do not see how this justifies "collections."

Ada programs need no OS; they're really only useful for (abstracted) I/O, 
for everything else, they're mainly in the way.

>>> 2. What is worse that a collection is not bound to the pool. It is to an
>>> access type, which may have a narrower scope. So the user could declare 
>>> an
>>> unfortunate access type, which would corrupt objects in the pool and the
>>> pool designer has no means to prevent that.
>>
>> Pools are extremely low-level things that cannot be safe in any sense of 
>> the
>> word. A badly designed pool will corrupt everything. Using a pool with 
>> the
>> "wrong" access type generally has to be programmed for (as I answered
>> earlier, if I assume anything about allocations, I check for violations 
>> and
>> do something else.) And a pool can be used with many access types; many
>> useful ones are.
>
> This is also true, but again unrelated to the point that tying 
> finalization *without* deallocation to a pointer type is just wrong, 
> semantically on any abstraction level.

If you didn't finalize everything, then a system like Claw would not work, 
since there would be objects that would have gotten destroyed (when the 
access type goes out of scope) and would still be on the various active 
object chains. (The whole reason that these things are controlled is so that 
they can be added to and removed from object chains as needed.)

Now, you could say that no one should be declaring access types locally in 
subprograms -- I'd agree with that, but it isn't Ada.

Even if your semantics only happened for library-level access types, then 
you'd still have problems when library-level objects go away. I suppose you 
could say those never go away either -- but again, that only makes sense for 
programs that never terminate. On Windows, you would have a mess.

                Randy.