apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: freelists: a slightly different approach
Date Fri, 28 Sep 2001 20:09:36 GMT
On Friday 28 September 2001 12:24 pm, 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 over time, the number of buckets used will stabilize, and we will
see a performance improvement by not having to allocate the buckets each
time.  Also, there is no way to get the conn pool in each bucket list. Also,
the conn pool is incorrect, because we can leak like a sieve if we do that.
Imagine a connection that has 100 requests for files on it.  That can be handled
by two or three buckets, but if we allocate out of the conn pool, we will
create two to three hundred, because they won't be free'd between requests.

Ryan
______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message