On Wed, Sep 26, 2001 at 02:42:14PM -0400, Cliff Woolley wrote:
> bit alone might disqualify it.) Oh well, it wouldn't kill us to have a
> static array in each MPM that's the appropriate size and to just use that,
> indexed by the second half of AP_CHILD_THREAD_FROM_ID. As long as they
> get stored somewhere in Apache and not in apr-util I'm happy.
I'd rather see it stored in apr-util not httpd. =-/
You're trying to store internal information about the buckets in
httpd and I'm not a fan of that (opaque pointer or not). This code
to store the freelists would have to be duplicated by anybody that
uses buckets - I'd like to see flood use buckets and brigades. As
I said, this just seems like an incorrect way to go about it.
It also breaks all sorts of abstractions. IMHO, sending in a unique
identifier (such as c->id in the case of httpd) sounds like a fair
compromise though - that's iffy though. I'd rather see Greg's
suggestions of a linked-list of arrays indexed by the thread id. I
just think that all of this should all be hidden by the bucket code.
apr_bucket_get_my_freelist()
{
#if APR_HAS_THREADS
apr_os_thread_t tid = apr_os_thread_current();
for all elements in the internal linked-list
search for free-list associated with tid by
apr_os_thread_equal(tid, l->tid)
if no match found in linked-list
create a new freelist for our tid
attach to the linked list
return match
#else
only-one-free-list, so return it.
#endif
}
Note that since we're basing it off our thread id, it is impossible
to have any sort of collisions (threads aren't reentrant). Therefore,
you don't need to lock the walking of the lists. (Actually with
a linked-list implementation, you *may* actually have a small race
condition as you attach the new freelist to the list and you get
interrupted mid-statement and someone is at the very end of the
list - ack.)
I think a hashtable would be faster as you wouldn't have to do
a linear search and removes the race condition above, but
whatever - people seem to think hashes are slow. FWIW, I'm
picturing threads in the 100s or 1000s per process as the eventual
typical case for httpd (flood already scales that high), so the
balance shifts from a naive linked-list to a hashtable, IMHO.
-- justin
