apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maxim Yegorushkin" <maxim.yegorush...@gmail.com>
Subject Re: custom memory allocators ?
Date Wed, 12 Mar 2008 20:37:27 GMT
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 :(


On 12/03/2008, Ryan Bloom <rbloom@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 <minfrin@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

View raw message