httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Williams <>
Subject Re: ap_pool support for shared memory?
Date Tue, 27 Jun 2000 22:33:48 GMT
On Tue, 27 Jun 2000 wrote:

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

These do help, but I would like to have the ability to call existing
functions such as ap_psprint, ap_make_table, ap_palloc, etc. and have
the low-level memory allocation call use ap_shm_malloc (or similiar)
instead of standard malloc.  Then have free_blocks call ap_shm_free
when the pool is destroyed.

To gain the memory management benefits of pools, plus the ability to
control their placement.

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

Thanks.  I don't have a patch ready yet, but wanted some feedback on
whether such a change would possibly be accepted back into the


> > 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
> none-the-less.
> Ryan
> _______________________________________________________________________________
> Ryan Bloom               
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------

View raw message