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 Wed, 26 Sep 2001 15:16:00 GMT
On Wednesday 26 September 2001 01:00 am, Greg Stein wrote:
> On Wed, Sep 26, 2001 at 12:03:55AM -0700, Justin Erenkrantz wrote:

> > What's wrong with an internal hashtable here keyed off of the
> > thread id (or whatever is returned by apr_os_thread_current)?
> > Internally, you can represent the apr_bucket_freelist* as you
> > describe (that sounds good) - so we can abstract all of that
> > away, but forcing this out to the caller seems like the wrong
> > direction to go.  The hashtable makes it so that it is of
> > indeterminate size and the retrieval speed should be fast
> > enough for our purposes.
> >
> > Or, what am I missing?  -- justin
> An internal thread id seems more than fine. We can always expose more
> details later on, as we find we need to fine tune things.
> That thread id would then give you an array of chains of free buckets. That
> array can be indexed by the bucket size, say rounded up to the nearest 8 or
> 16 bytes. Buckets over size N fall off to a separate structure to associate
> sizes with the chains. That gives us speed for "normal" buckets, yet allows
> us to handle arbitrary size buckets.
> I believe the optimal structure for the chain is a pair of items:
> * a free list of buckets, in a simple linked list
> * a block of free buckets, specified as ptr to current and N left
> The free list optimizes the "free bucket" operation to be a simple linking
> process.
> Allocating a bucket goes to the free list first, then to the block. Both
> are very fast operations. If none are available, then a new block is
> allocated and the ptr/N pair are initialized.
> By using the pair, we optimize the alloc-new-block operation: linking N
> buckets into the free list is expensive. Dropping the new allocation into a
> block is the fastest operation. But putting free buckets back into that
> block is expensive, so we add in the free list.
> A bucket can simply record a ptr to its chain.
> So... the hard part is figuring out which chain to use when allocating a
> bucket. Like I said above, I would suggest a simple mechanism (for
> starters) which maps the thread id to an array of chains. Note that this
> does not require any API changes. Heck, it doesn't even need an API change
> for setting up the structures -- not to the bucket allocs and not even the
> apr_bucket_alloc stuff.

I would suggest not using a thread ID.  They are incedibly non-portable.  
Windows uses HANDLEs instead of ints.  This is why I originally suggested
using the c->id number, and letting Apache handle which thread is doing the
work.  Other than that, what you said above is exactly what I've been saying all
along, so I have to agree with all of it.


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

View raw message