Re: Ada.Containers and Storage_Pools

[Matthew Heaney <mheaney@on2.com>]

msimonides@power.com.pl wrote:
> I'm working on a caching DNS resolver for our project. The structures
> used to hold data in cache make use of Ada.Containers packages (e.g.
> each node stores a map of list resource records for each data type, so
> there is a lot of individual containers).

OK, it sounds like you have a map container whose elements are list 
containers.  Is that right?


> The problem I'm facing (and that is certain to show up in other parts
> of our project) is that I need to limit the size of cache in memory. To
> do this I would need to be able to have the containers allocate their
> nodes from a user-specified storage pool with some limiting mechanism
> (I already have such a pool and use it for objects that are allocated
> by my code).

Is the pool bounded or unbounded?  In other words, can you run out of 
nodes?  If so, what should happen?



> So I have a question: is there a possibility, either in GNAT 3.4.5 or
> in Ada 2005, to specify a custom storage pool for use by containers? If
> not, is there any other solution to limiting the size of memory used by
> containers?

Our philosophy in the design of the Ada 2005 container library was to 
optimize around the common case.  Unfortunately, your application needs 
a custom storage pool and hence is not common case.  So no you can't 
specify a custom storage pool.

One possibility is to keep a list around and use it as a kind of storage 
pool for the list objects that are map elements.  You can use the Splice 
operation for lists to move list nodes between list objects (that are 
map elements) and the list object that serves as the pool.


> The only solution that I have found is using some other containers
> library (I've seen that Booch components allow for specifying custom
> storage pools), but I'd really prefer to stick with the standard ones.

I'd like to know more about what you're doing, and about the nature of 
your storage pool.  If you don't mind drop me some email so we can 
discuss your issues in more detail.

Thanks,
Matt