httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: ap_pool support for shared memory?
Date Tue, 27 Jun 2000 21:44:45 GMT
On Mon, 26 Jun 2000, David Williams wrote:

> I may have a need to use shared memory, but would also like to use the
> pool routines found in apr_pools.c, since they simplify memory
> management.  The current obstacle being that these routines only call
> malloc/free.  Has any one else had a similiar need, or see reasons
> they could not be enhanced?   I was thinking along the lines of
> something similiar to:

Take a look at the ap_shm_* functions.  They are actually using their own
pool implementation.  I think this will be enough for what you are looking

> A) In addition to the existing ap_create_pool(), add a companion
> ap_set_pool_allocator( void *opaque_allocator_object,
>                        void (*pool_malloc)(void *opaque, size_t size), 
>                        void (*pool_free)(void *opaque, void *ptr) );
> Or combine with ap_create_pool() to create a new
> ap_create_pool_with_allocator() type call. These 3 parameters would be
> stored in ap_pool_t for later retrieval
> B) Update malloc_block() and other apr_pools.c routines to call the
> pool_malloc()/pool_free() when they have been set for that pool. 
> Subpools would inherit these allocate/deallocate routines.

We looked at re-vamping our memory allocation model at the beginning of
2.0, and we never really came to a good conclusion of how to do it
right.  If you want to submit I patch, I will answer any questions that I
can to help.

> Also I was curious: 
> 1. Is ap_create_pool() located in lib/apr/misc/*/start.c in order to
> be platform dependent?  The code looks the nearly same between
> platforms, with the beos version slightly different from the other
> two, though it is not clear why.

I think you need to update your code.  Currently, the only start.c is in
lib/apr/misc/unix.  The beos and Windows versions were removed because
they were just duplicate code.

> 2. ap_shm_init() has a ap_pool_t parameter that is not used.  As if
> someone had thought of tying the shared mem to a pool (instead of the
> other way around)?

One overriding feature of APR is that all APR functions take a pool
*.  This is because it is impossible for the APR developers to be able to
predict when a new platform will be added that will need to be able to
allocate memory in one of the APR functions.  This would be much more
useful with a new memory management model, but it is useful now


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message