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.
Ryan ---------- 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 <[EMAIL PROTECTED]> To: Cliff Woolley <[EMAIL PROTECTED]> Cc: <[email protected]> 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. Ryan > 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 > [EMAIL PROTECTED] > Charlottesville, VA -- ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -------------------------------------------------------------- ------------------------------------------------------- -- ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
