Re: Custom Storage Pool questions

[Jere <jhb.chat@gmail.com>]

I think the only thing that misses is scenarios where the compiler vendor 
isn't allocating a descriptor/bounds but is still using multiple allocations for the
object.  I don't know if that is a practical use, but it is one the RM allows?  If
so, it is probably more useful to know if a specific Allocate call is somehow
a unique call relative to the others (the first call, the last call, etc.) so that the
developer could earmark that one to be the one to add the custom header
to.  

We can't change the Allocate specification since it is what it is, but is there
any consideration to adding functionality to the root storage pool type,
maybe a classwide function that lets the compiler developer set an internal 
flag for that unique allocation and a classwide function for the storage
pool developer to see if that flag was set for the allocation.  Or some other
mechanism.  It seems like this would need to be some sort of runtime 
mechanism if the multiple allocations can occur in the absence of needing
a descriptor or bounds.

Or maybe a generic version of the Storage_Pools package that allows a 
header type to be specified, that gives the compiler vendor some 
interface that easily facilitates allocating the header along side any object
at the time and place the vendor finds convenient, and provides the 
custom storage pool implementer a means of knowing when that happens
so they can initialize the header in the allocate function that creates it.

I'm obviously not a compiler developer so I don't know the practicalness
of any of that.  But I think one root problem for a custom storage pool 
developer is "when is it safe to make a custom header for my object?".  



On Monday, September 20, 2021 at 8:50:41 PM UTC-4, Randy Brukardt wrote:
> A better solution would be to know the size of those bounds objects and 
> treat them differently (I've done that). And the next allocation is going to 
> be the data, so I don't do anything special for them. Probably would be nice 
> to have an attribute for that. But no one has ever asked for any such thing, 
> so I haven't defined anything. 
> 
> Such pools are highly implementation specific, so I haven't worried about 
> this much.. 
> 
> Randy. 
> 
> "Emmanuel Briot" <> wrote in message 
> news:44be7c73-f69e-45da...@googlegroups.com...
> >> > If a compiler is allowed to break up an allocation into multiple 
> >> > calls to Allocate (and of course Deallocate), how does one go about 
> >> > enforcing that the user's header is only created once? 
> >> I think one cannot enforce that, because the calls to Allocate do not 
> >> indicate (with parameters) which set of calls concern the same object 
> >> allocation. 
> > 
> > I think the only solution would be for this compiler to have another 
> > attribute similar to 'Storage_Pool, but that would define the pool for the 
> > descriptor: 
> > 
> > for X'Storage_Pool use Pool; 
> > for X'Descriptor_Storage_Pool use Other_Pool; 
> > 
> > That way the user can decide when to add (or not) extra headers.