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
