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/[email protected]/msg19579.html On 12/03/2008, Ryan Bloom <[EMAIL PROTECTED]> 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 <[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] >
