apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Bradford <bradford...@gmail.com>
Subject Memory Pool Revisions
Date Wed, 03 May 2006 22:26:34 GMT
I remember reading that the dependency on memory pools was going to  
be modified so that a developer would have a choice in allocation  
between memory pooling and some other method.  I was wondering what  
the 'other method' would be, and if the developer herself could  
assert some control over it.

Furthermore, perhaps instead of a memory pool, we step back a little  
bit and call a simplified form of these things 'memory managers',  
where they continue to effectively have the same interface, but their  
behavior depends on the form of manager that is instantiated.   
Another nice addition would be extending the memory pool system so  
that the pool exposes a 'free' function for explicitly freeing  
items.  I can see a couple potential implementations:

- Memory Pool Manager, as we have now... we delete the managed memory  
when the memory pool is destroyed, but we also allow for explicitly  
deleting items within the lifetime of a memory pool.
- Boehm Manager... This is the one I'd be particularly interested  
in.  It would interface with the boehm garbage collector and  
iteratively delete things that can no longer be reached.

The Memory Pool Manager would continue to be the complicated set of  
code that it already is, while the Boehm manager would effectively  
just be an adapter for GC_malloc.

Also, we need a function for realloc in the current implementation.   
Obviously, performing a realloc on a memory pool-allocated pointer  
may cause the memory pool code to attempt to free a pointer that is  
no longer in its control.

Thoughts?

--
Tom Bradford - http://www.tbradford.org/



Mime
View raw message