apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: freelists: a slightly different approach
Date Wed, 26 Sep 2001 19:21:37 GMT
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_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
    only-one-free-list, so return it.

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

View raw message