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 lifetime. 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? -aaron
