apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: freelists: a slightly different approach
Date Wed, 26 Sep 2001 07:03:55 GMT
On Wed, Sep 26, 2001 at 12:05:33AM -0400, Cliff Woolley wrote:
> 
> Okay, I've been thinking about this a lot today.  I think I've come up
> with a better design for this freelist scheme.  The problem with the
> current scheme is that it's very implementation specific... for example,
> changing from SMS to the pass-in-an-int-list-number scheme required
> changing the API, and the new version of the API basically implies a lot
> of information about how we're implementing the free lists.  I think it
> would be much better to do the following:
> 
> 1) each thread that wants to use buckets must call a function called
> something like "apr_bucket_freelist_init(thread_pool)"  which returns a
> pointer of some opaque type.  Something like this:
> 
> apr_bucket_freelist *apr_bucket_freelist_init(apr_pool_t *thread_pool);
> 
> 2) the thread must simply remember the returned pointer and pass that in
> to all calls to _bucket_foo_create().

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


Mime
View raw message