You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by David Williams <dw...@cisco.com> on 2000/06/27 02:46:51 UTC
ap_pool support for shared memory?
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:
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.
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.
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)?
thanks,
-david
Re: ap_pool support for shared memory?
Posted by rb...@covalent.net.
> > 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
> codebase.
I think a patch would be VERY welcome. I would suggest that you look at
the archives from about February of last year. You could try the hypermail
archives. Look for the thread on which Dean was talking about using pools
to simulate malloc and shared memory allocation. I can't remember the
thread subject, but it was around February of last year I think.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: ap_pool support for shared memory?
Posted by David Williams <dw...@cisco.com>.
On Tue, 27 Jun 2000 rbb@covalent.net 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
codebase.
-david
>
> > 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 rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
>
Re: ap_pool support for shared memory?
Posted by rb...@covalent.net.
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.
> 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
none-the-less.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------