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 [EMAIL PROTECTED] Charlottesville, VA
