apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Fwd: Re: bucket free lists (was Re: [PATCH] buckets sms phase 2)
Date Sun, 23 Sep 2001 22:15:01 GMT

I don't know if this made it to the list the first time, because my
network went down as I tried to send it.


----------  Forwarded Message  ----------

Subject: Re: bucket free lists (was Re: [PATCH] buckets sms phase 2)
Date: Sun, 23 Sep 2001 14:57:39 -0700
From: Ryan Bloom <rbb@covalent.net>
To: Cliff Woolley <cliffwoolley@yahoo.com>
Cc: <dev@apr.apache.org>

On Sunday 23 September 2001 02:22 pm, Cliff Woolley wrote:

Mostly good.  I did notice a few ommissions that will be necessary.

apr_status_t apr_bucket_list_init(int num_threads)

This function creates the static array.  We need to tell them how many
threads will be creating pools.

I assume we'll be removing the apr_bucket_*create_in functions once
the code is finished.

I am trying to decide if we should pass in a pool or an integer. I think we
 need to at least associate a pool with each array slot.  That way, the
 buckets will always be allocated out of a pool, so that they are guaranteed
 to be cleaned up properly.  The reason to not pass a pool each time, is that
 we want to thread pool to be the pool associated with array slot, not the
 request pool.

So, I think we will also need:

apr_status_t apr_bucket_list_pool(int num, apr_pool_t *p)

Feel free to change that name.

I am not sure about using the value from apr_thread_current to do this.
That function just returns a tid from the OS, so it unlikely to be really
useful.  The core should just use the thread id, which can be retrieved
cleanly from the conn_rec->id field, using AP_CHILD_THREAD_FROM_ID.

That will be faster, because we don't need to call into the thread libs, and
it is more likely to work cleanly.


> 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) \
>         apr_bucket_foo_create_in(thisfoo,apr_bucket_list_find())
> 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
> --------------------------------------------------------------
>    Cliff Woolley
>    cliffwoolley@yahoo.com
>    Charlottesville, VA


Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net



Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message