comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Comprehending subpools
Date: Fri, 15 Jun 2018 17:15:21 -0500
Date: 2018-06-15T17:15:21-05:00	[thread overview]
Message-ID: <pg1dpq$dsb$1@franka.jacob-sparre.dk> (raw)
In-Reply-To: pfvp1k$ph4$1@gioia.aioe.org

"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. For almost all implementations, 
attempting to do that with controlled objects would cause the program to 
instantly crash because of an attempt to follow pointers that no longer 
exist.

Since virtually all memory management schemes in Ada use controlled types or 
some language-defined equivalent, that essentially means that you would be 
so limited in what you can put into such a pool that it is close to useless.

> 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.

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.

Draw your own conclusions as to how valuable (or not) that is.

                                       Randy.



  reply	other threads:[~2018-06-15 22:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-14 13:48 Comprehending subpools sbelmont700
2018-06-14 21:21 ` Randy Brukardt
2018-06-15  7:15   ` Dmitry A. Kazakov
2018-06-15 22:15     ` Randy Brukardt [this message]
2018-06-16  7:36       ` Dmitry A. Kazakov
2018-06-19  0:32       ` sbelmont700
2018-06-29 19:57         ` Randy Brukardt
2018-06-29 22:42           ` Shark8
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox