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 17:13:05 GMT
On Wed, 26 Sep 2001, Ryan Bloom wrote:

> That's fine.

Will I get lynched if I further suggest putting this thing in the
scoreboard?  We've got our conn_rec->id that gives us a handy lookup into
the scoreboard, so it seems a logical place to put it.  Or it can just be
a separate array, though the dimensions of that array will basically
mirror the dimensions of the scoreboard anyway.

> Of course, you could just as easily pass an ID to the bucket API.

Certainly.  But then the bucket API would have to map ID's to lists.  The
nice part of the abstraction is that an apr_bucket_freelist* can be
anything... it can even be a plain old integer casted as a pointer if we
like.  I believe it's more efficient and more flexible to have the thing
be an actual pointer to the freelist, so that's what I'm going to try.
But the key part is that as long as it's abstract, we can settle on an API
that fits our needs and then dink with the implementation till we're blue
in the face.

> Then, you keep the abstraction, because the bucket API just ends up
> accepting an ID to the create function.  That ID ends up being an
> integer, but conceptually it is just a unique identifier.  You could
> also create a simple function to return a unique ID to the caller, so
> that if the program didn't have their own ID, we could provide one.

That's basically what I'm saying we should do anyway with
apr_bucket_freelist_init() or whatever I called it... the caller really
doesn't much care what it receives and passes back.  The only difference
is that with a generic "unique ID", the caller can make up their own.

That just means more work for us though.  Whatever.


   Cliff Woolley
   Charlottesville, VA

View raw message