httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: memory allocation (was Re: Why bother with APR?)
Date Mon, 13 Sep 1999 20:31:34 GMT
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.

> i think of a pool as really a place to store cleanups.  in essence,
> a pool could just be a list of cleanups. 

That's how I've always thought of it. The memory allocation stuff is
just a nice performance tweak.

> and ap_shmalloc() could register a cleanup for the shared mem
> allocations...

Apparently, supporting pool-like operations in shared memory isn't
portable once you aren't in Unixland anymore.

Manoj Kasichainula - manojk at io dot com -

View raw message