apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: freelists: a slightly different approach
Date Fri, 28 Sep 2001 19:34:37 GMT
On Fri, Sep 28, 2001 at 12:24:49PM -0700, Justin Erenkrantz wrote:
> 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."

Because we want to optimize the freelist for use with bucket allocation,
and we can do that best if we try to reuse free'd buckets. I think the
hope is that we can come up with an algorithm that quickly reaches
a stable state over the lifetime of the thread (worker thread or prefork
child), which means it has to live outside of a particular connection pool

This is what I was alluding to in my absurdly vague message early on in
this thread. What I failed to realize at the time was that we don't have
a good way of getting that pool/freelist pointer deep into our filter
APIs. Am I looking at this correctly now?


View raw message