apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: freelists: a slightly different approach
Date Wed, 26 Sep 2001 08:59:14 GMT
On Wed, 26 Sep 2001, Greg Stein wrote:

> 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.

See my response to Justin.

> 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

This is what we've been talking about doing all along.

> 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)

The very simplest method is one which involves no extra computation at
all.  :)  Yes, it's an API change, but I honestly believe we're going to
have to change the API anyway.

> 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.

Are you suggesting that the buckets themselves call
apr_os_thread_current() or something every time you create a bucket...
wow, that would get really expensive really fast.  Or have I missed your
point?

--Cliff


--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA



Mime
View raw message