httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: memory allocation (was Re: Why bother with APR?)
Date Tue, 14 Sep 1999 16:43:27 GMT

On Mon, 13 Sep 1999, Manoj Kasichainula wrote:

> On Tue, Sep 07, 1999 at 04:00:19PM -0700, Dean Gaudet wrote:
> > so i'm thinking that it may not be possible to decide ahead of time what
> > type of memory allocation should be associated with a particular pool.
> > that is to say -- some users of a pool may want palloc-style allocation,
> > which isn't freed until pool destruction, and other users may want
> > malloc/free style which can be freed at will. 
> > 
> > there's two reasons i'm thinking along these lines -- the first is that
> > some users of a pool may be a cache, and could be hidden behind a library
> > interface.  the second reason is that i don't like lots of conditionals ;) 
> If pools will support malloc/free, I'd like to add another function to
> the pool interface:
> ap_run_cleanups(struct context_t *p, void *data);
> It would work like ap_run_cleanup, but it would execute all the
> cleanups for a given pointer. With this addition, it becomes possible
> to support malloc/free-mode and the current system without the app
> actually having to care which was used.
> If an app wants to support freeing a pointer's memory on-demand, it
> simply calls ap_run_all_cleanups on the pointer. If the pool used its
> own memory chunk to allocate the memory, it won't do anything because
> no actual cleanups were registered. But if malloc was used, the memory
> will get freed. And anything missed by the application will get freed
> when the pool is cleaned out in both cases.

note:  when i was suggesting adding cleanups for malloc'd memory i really
wasn't suggesting that a cleanup be added for each piece of malloc'd
memory.  that will consume a fair bit more memory per allocation... i was
actually thinking the solution would be to prefix the malloc allocation
with a struct mem { mem *next; mem *prev }; ... and having a single
cleanup which walks the entire list of malloc allocations.

although at some point here we start arguing about how to implement
generic linked list support ;)


View raw message