apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <rbl...@gmail.com>
Subject Re: custom memory allocators ?
Date Wed, 12 Mar 2008 19:12:32 GMT
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.


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

View raw message