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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
