apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject bucket free lists (was Re: [PATCH] buckets sms phase 2)
Date Sun, 23 Sep 2001 21:22:47 GMT
On Mon, 3 Sep 2001, Ryan Bloom wrote:

> On Monday 03 September 2001 18:49, Cliff Woolley wrote:
> > On Mon, 3 Sep 2001, Ryan Bloom wrote:
> > > I seriously dislike adding an SMS to every bucket.  I believe we are
> > > much better off just creating a per-thread free bucket list.  That
> > > keeps us from ever calling free while dealing with a request, and over
> > > time, we will stop calling malloc.
> >
> > Okay, let's examine this option for a minute.  There are two ways to do
> > this: either the buckets code handles it or httpd handles it.  If the
> > buckets code handles it, you have to do the thread lookups we talked about
> > before, which is bad.  So that pretty much means it's up to the httpd to
> > handle it.  So what's the easiest way to do that?
> The bucket code has to handle this.  The easy way to do this, is to pass in
> an integer which corresponds to which bucket list to use.

Okay.  Just so I'm sure we're on the same page before I go and code this
whole thing up, attached is a diff to apr_buckets.h that should make it
obvious what I'm proposing that we do.

Basically, I've taken all of the current _foo_create() functions and
renamed them to _foo_create_in() [name negotiable] and added an extra
parameter, which is just an int that tells you which list to use, as you
suggested.  Then there's a new function called apr_bucket_list_find()
[name negotiable] that returns said int, basing it on the results of
apr_os_thread_current() or something like that.  I've then created macros
for all of the _foo_create() functions of this form:

#define apr_bucket_foo_create(thisfoo) \

That way, if a caller wants to be efficient, he can call
apr_bucket_list_find() himself and store the value and use the
_foo_create_in() functions directly.  The #define's let us preserve the
original API and migrate toward that approach more slowly and/or only
where really needed for performance.  [How slowly probably depends upon
how expensive apr_os_thread_current() is.]

Does this seem reasonable?


   Cliff Woolley
   Charlottesville, VA

View raw message