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 Thu, 23 Sep 1999 07:12:37 GMT
On Tue, Sep 21, 1999 at 02:07:25AM -0700, Dean Gaudet wrote:
> it'd be cool if we could stop calling the memory allocator a pool, it
> confuses things...

Well, we need another name for it, then. 1.3pool? 

> - or you could adjust the malloc size by sizeof(void *) and stick a
>   back pointer to the cleanup in it... but if you're going to do this,
>   you might as well adjust the malloc size by sizeof(struct mem)
>   where struct mem { mem *next; mem *prev };.  this way free() is
>   O(1).

The only (minor) problem with this is that we may tend to malloc in
powers of 2 (I should look, but I'm lazy), and this addition might
cause memory to be wasted. It would in the basic mallocs I learned
about in school.

> - don't use malloc/free to implement ap_malloc/ap_free.  instead grab
>   some malloc implementation (such as *bsd's) and modify it to
>   use ap_palloc underneath instead of going through brk()/sbrk().

Other than having to bundle our own malloc, this sounds very cool.

> - ap_malloc and ap_free are not associated with pools at all, the users
>   of them have to do their own resource management.  this is exactly
>   the route i've taken already if you look around at the few malloc()s
>   i put in.

For the shared cache case, this is no big deal. We'd have to maintain
reference counts to ensure that a cached object isn't pulled out from
under anyone anyway. Any automatic cleanup scheme would only serve to
hide bugs in the reference counting algorithms.

Manoj Kasichainula - manojk at io dot com -

View raw message