Re: Comprehending subpools

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-06-16 00:15, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pfvp1k$ph4$1@gioia.aioe.org...
>> On 2018-06-14 23:21, Randy Brukardt wrote:
>>
>>> The use case is situations when you have separable data structures that
>>> it
>>> only makes sense to treat as a whole. Think of an expression tree in a
>>> compiler. There are a lot of inter-structure links, so a reference
>>> counting
>>> scheme for every pointer doesn't work. Rather, you can use a subpool and
>>> only reference count the references to the entire tree. When that goes to
>>> zero, you use the subpool to clobber the entire structure. Alternatively,
>>> you might have weak references to the tree, that automatically get nulled
>>> when the tree is clobbered.
>>
>> I think the questions rather were:
>>
>> 1. What is so special about arena or a mark-and-release pool that it
>> cannot be handled by a user-defined pool in Ada 95?
> 
> No pool that does block deallocation (not using Unchecked_Deallocation) can
> work properly with controlled objects.

Yes, but that was the second question. The first was if arena can be 
implemented in Ada 95. It can.

>> 2. Arena is inherently unsafe whatever implementation used. So all talk
>> about "safety" does not make much sense.
> 
> "Safety" in this case is related to properly handling controlled types. With
> that, one can construct properly working strong and weak references and
> other safe memory management structures that will work on essentially any
> Ada objects. Without it, you have no chance of any safe memory management.
> 
> The basic idea is that one manages the "strong" references to an arena (such
> as the reference to the root of a tree), and when they are all gone, one can
> safety destroy the arena. The weak references aren't managed for that
> purpose, but don't become erroneous when the arena is destroyed, but rather
> just get (effectively) nulled out.

In effect it means that all references to the objects also hold a 
reference to the pool. It is no problem to implement with an Ada 95 pool.

> One could implement the containers this way, such that when a container is
> destroyed, that the entire arena of nodes is immediately reclaimed. (There's
> no legal references into the container at that point.)
> 
> In any case, a subpool by itself doesn't provide any safety; it's just a
> building block to be used to provide such safety. All of the other things
> needed to build such abstractions already existed in Ada, the only thing
> missing was an ability to finalize all of the objects in an arena (subpool)
> at once.

Right, it is so special case that I join OP wondering why this was paid 
any attention at all. Normally the schema is reverse, the objects must 
go when the arena goes, if any safety could be added, then a linked list 
of objects to finalize [prematurely, BTW] as it is done in other cases.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de