apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: freelists: a slightly different approach
Date Fri, 28 Sep 2001 19:24:49 GMT
On Wed, Sep 26, 2001 at 04:51:11PM -0700, Brian Pane wrote:
> I disagree.  We typically don't make APR data structures responsible
> for their own memory management; rather, most things require that the
> caller provide an appropriate pool, because the application can make
> better choices about threads and resource management.  I think the
> same pattern can be applied to buckets; the only exception is that
> they need a free-list instead of a pool.

Okay, thinking of as a pool places it in a different light for me.
I was thinking of it as merely an extension to the bucket code
rather than as something completely separate.

Here's an off-the-wall suggestion, why can't the buckets simply
use the connection pool for allocation?  Anything that is allocated 
for a bucket in httpd must have a defined lifetime no greater than 
the socket that the connection was created in - I'm not sure I see 
any need for keeping buckets around *after* the socket has closed.
Am I missing something?  Why can't we just simply use pools again?
I think Sander (?) posted a patch that explicitly frees a chunk of 
memory from the pool, so we should be able to use that to minimize
starvation when a bucket is "freed."

> The *only* reason we've gotten this far without per-thread
> free lists for pools is that most apr_palloc() calls in the
> httpd happen to be small enough to work without additional
> block allocations from the global free list.  In general, I
> don't think it's a bad idea to provide an alternate API for
> pool creation that says, "give this pool and its children
> a private, non-mutex-protected free list."

That's what Sander's pool replacement patch does, IIRC.  
-- justin


Mime
View raw message