apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: freelists: a slightly different approach
Date Wed, 26 Sep 2001 15:34:28 GMT
On Wed, Sep 26, 2001 at 12:03:55AM -0700, Justin Erenkrantz wrote:
> Something strikes me as incorrect with this.  First, it'd require
> initialization of this code per thread and then they'd have to store
> it globally so that all of the code that calls _bucket_foo_create()
> can pass it - but since threads typically share memory space with
> their sibling threads, they'll need to create the data structure
> themselves.  And, this code will have to be duplicated by any 
> user of buckets.
> 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

In trying to get my handle on this thing, I came up with a couple

How is this different than an SMS specificially designed for buckets? From
my POV, take away the function pointers from SMS and we're left with a
memory allocator that has a definite lifetime (it takes on the lifetime
of the thread), can free as well as alloc, and is as optimized for the
particular problem of bucket allocation.

You can also view this as a special case of a pool, only one where there
is an explicit freelist that knows a little about the sizes of chunks
it will be getting back and redistributing. Hide those details behind
something like a thinner SMS and we've got it, no?

In either case you still have to create this structure and tie it to
some pool of the appropriate lifetime, which means it's going to have
to happen sometime after the thread's pool is created and before the
first connection is processed.


View raw message