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:50:42 GMT
On Wed, 26 Sep 2001, Justin Erenkrantz wrote:

> Something strikes me as incorrect with this.  First, it'd require
> initialization of this code per thread ... And, this code will have to
> be duplicated by any user of buckets.

That's going to be the case with any method you choose.  Using a hash
table and the thread ID, you have to go one further... you have to
initialize per child [the hash table] and THEN per thread [each list].

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

It's not that hard really... all threads already have private storage.  It
can be kept on the stack or in a thread-private pool or anywhere.  So it's
not really "global".  The basic idea is to shove it into the conn_rec for
each connection or somewhere equally easily accessible.

> What's wrong with an internal hashtable here keyed off of the
> thread id (or whatever is returned by apr_os_thread_current)?
> and the retrieval speed should be fast enough for our purposes.

Two things.  One, by using the thread ID and not just some arbitrary
pointer value, it ties us in to a certain set of possible implementations
[see below].  Two, I just think it will be wastefully slow if we have to
use a hash table.  By wastefully slow, I mean that you're doing a _ton_ of
redundant computation.  For each bucket you allocate, you might have to
rehash two or three times.  Wow.  That's no good.  Maybe it would be 'fast
enough', but it could very easily be much, much faster.  That's all I'm

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

We're forcing it out to the caller any way around.  Surely we don't want
to have to call apr_os_thread_current() every single time we allocate a
bucket.  So we're already going to be storing the value in the caller.
The only difference is whether we hide what we're doing from the caller
(by making the apr_bucket_freelist* be the public interface) or allow the
caller a glimpse at what we're doing (by using the thread ID).  It happens
that it's way more convenient for the buckets if we use the hiding

I think the problem here is that it it sounds to you like we're placing a
big burden on the caller.  But if you stop to think about it, I think
you'll see that it's no more burden than any other method (in fact,
exactly the same amount).  I guess I just need to code the damned thing up
so you can see.  I was getting sick of rewriting this thing fifteen
different ways, but I'm now convinced that this is the right way to go, so
I guess I just have to go and do it if I'm going to convince you all as
well.  =-)


   Cliff Woolley
   Charlottesville, VA

View raw message