custom memory allocators ?

[Adrian Stan <ad...@yahoo.com>]

Hello all,

I have just started using apr for a client-server project. A lot a functions have an apr_pool as parameter, so that all the allocations inside the functions are done within the pool (using functions as apr_pcalloc for example). I don't want to use pools for my project, but instead I want to use my own memory allocation scheme. Is there a way to configure apr so that to use my own memory allocator  ?
It appears to me that apr wasn't design flexible enough to allow this.
Why was chosen this method for memory allocations instead providing some function pointers in a structure, something like this:

void my_func (my_allocator* allocator)
{
    allocator->alloc(bytes);
    .....
}

where my_allocator is a structure defined something like:

struct my_allocator
{
...
    void * (*alloc)(size_t bytes);
....
}

this way, the user had a chance to substitute his own function to be used for allocation purposes, instead of forcing the user to use the existing pool based allocation mechanism ...
Pool based allocation is good for some class of applications indeed, but the library should be flexible enough to allow the user to specify his own memory allocation scheme (or not to use one at all and to directly allocate memory on the heap using malloc)

Thanks for your help.
Adrian


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.

Re: custom memory allocators ?

[Maxim Yegorushkin <ma...@gmail.com>]

A bit off topic here, however, I though you guys in this thread might
be interested that there is a small bug in the allocator, and there is
a patch submitted, but I got no responses :(

http://www.mail-archive.com/dev@apr.apache.org/msg19579.html

On 12/03/2008, Ryan Bloom <rb...@gmail.com> wrote:
> We did at one time (years ago) look at adding the flexibility that you
>  are talking about here.  It has a serious impact on performance of the
>  Apache web server, which was the reason the code was removed from the
>  system.  Also, the reality is that you can't really swap memory
>  allocation schemes easily in the middle of development, because the
>  code is usually written to assume a specific memory allocation scheme.
>   Consider going from pool-based memory to malloc/free.  None of the
>  pool-based code has calls to free, so the switch just doesn't work.
>  Large portions of APR allocate memory based on the pool model, so
>  changing allocation schemes would require quite a bit of rework to the
>  APR internals.
>
>  Having said all of that, having APR depend so closely on pools, is one
>  of my biggest regrets with APR in general.  I really wish that I had
>  listened to Manoj when I was originally prototyping the APIs, and had
>  provided an API to allocate the memory, and then passed the
>  pre-allocated structure into the method instead of passing around
>  pools.  But, I also remember the reasons for not implementing APR that
>  way, and they were valid, so I can't complain too much.
>
>  Ryan
>
>
>  On Wed, Mar 12, 2008 at 3:07 PM, Graham Leggett <mi...@sharp.fm> wrote:
>  > Adrian Stan wrote:
>  >
>  >  > Pool based allocation is good for some class of applications indeed, but
>  >  > the library should be flexible enough to allow the user to specify his
>  >  > own memory allocation scheme (or not to use one at all and to directly
>  >  > allocate memory on the heap using malloc)
>  >
>  >  I've never tried this, but would it not be enough to create a pool, use
>  >  the pool, and then destroy the pool directly afterwards if necessary?
>  >
>  >  The existence of pools significantly simplifies a lot of APR, because
>  >  you no longer need to keep track of whether a buffer you have been given
>  >  needs to be freed or not.
>  >
>  >  As a result, if a function needs to return a static string (for
>  >  argument's sake), it will just return the static string, instead of
>  >  returning a malloc'ed copy of the static string so that when the caller
>  >  calls free it will always work.
>  >
>  >  Regards,
>  >  Graham
>  >  --
>  >
>  >
>  >
>
>
>
>
> --
>  Ryan Bloom
>  rbb@apache.org
>  rbb@rkbloom.net
>  rbloom@gmail.com
>

Re: custom memory allocators ?

[Ryan Bloom <rb...@gmail.com>]

We did at one time (years ago) look at adding the flexibility that you
are talking about here.  It has a serious impact on performance of the
Apache web server, which was the reason the code was removed from the
system.  Also, the reality is that you can't really swap memory
allocation schemes easily in the middle of development, because the
code is usually written to assume a specific memory allocation scheme.
 Consider going from pool-based memory to malloc/free.  None of the
pool-based code has calls to free, so the switch just doesn't work.
Large portions of APR allocate memory based on the pool model, so
changing allocation schemes would require quite a bit of rework to the
APR internals.

Having said all of that, having APR depend so closely on pools, is one
of my biggest regrets with APR in general.  I really wish that I had
listened to Manoj when I was originally prototyping the APIs, and had
provided an API to allocate the memory, and then passed the
pre-allocated structure into the method instead of passing around
pools.  But, I also remember the reasons for not implementing APR that
way, and they were valid, so I can't complain too much.

Ryan

On Wed, Mar 12, 2008 at 3:07 PM, Graham Leggett <mi...@sharp.fm> wrote:
> Adrian Stan wrote:
>
>  > Pool based allocation is good for some class of applications indeed, but
>  > the library should be flexible enough to allow the user to specify his
>  > own memory allocation scheme (or not to use one at all and to directly
>  > allocate memory on the heap using malloc)
>
>  I've never tried this, but would it not be enough to create a pool, use
>  the pool, and then destroy the pool directly afterwards if necessary?
>
>  The existence of pools significantly simplifies a lot of APR, because
>  you no longer need to keep track of whether a buffer you have been given
>  needs to be freed or not.
>
>  As a result, if a function needs to return a static string (for
>  argument's sake), it will just return the static string, instead of
>  returning a malloc'ed copy of the static string so that when the caller
>  calls free it will always work.
>
>  Regards,
>  Graham
>  --
>
>
>



-- 
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com

Re: custom memory allocators ?

[Graham Leggett <mi...@sharp.fm>]

Adrian Stan wrote:

> Pool based allocation is good for some class of applications indeed, but 
> the library should be flexible enough to allow the user to specify his 
> own memory allocation scheme (or not to use one at all and to directly 
> allocate memory on the heap using malloc)

I've never tried this, but would it not be enough to create a pool, use 
the pool, and then destroy the pool directly afterwards if necessary?

The existence of pools significantly simplifies a lot of APR, because 
you no longer need to keep track of whether a buffer you have been given 
needs to be freed or not.

As a result, if a function needs to return a static string (for 
argument's sake), it will just return the static string, instead of 
returning a malloc'ed copy of the static string so that when the caller 
calls free it will always work.

Regards,
Graham
--