apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: freelists: a slightly different approach
Date Wed, 26 Sep 2001 19:30:39 GMT
On Wed, 26 Sep 2001, Justin Erenkrantz wrote:

[I'll respond to the rest of this later, I'm late for class]

> apr_bucket_get_my_freelist()
> {
>     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
> }

This isn't even close to optimal.  Here are just a few issues to think

(a) apr_os_thread_current() might be expensive.

(b) Even if it's not, if you allocate fifteen buckets in a single filter,
    you just asked the OS fifteen separate times in rapid succession for
    the same information.

(c) There's no need for a search here.  Any of the proposals involving
    an array or some other kind of storage where a thread gets its own
    slot per se will be much much faster.  Constant time, not linear, not
    even pseudo-constant like hashes.  No locking, ever.

(d) What about prefork?  Prefork can very easily have APR_HAS_THREADS,
    but it doesn't need to do all this gobbledy gook.  apr-util has no
    way to know that it has threads but only one of them will ever use
    this subsystem.  If we use one of the other methods, it doesn't have
    to know, because all of the freelist instances are independent.
    Looking up the freelist for a single-threaded app would be the
    essentially the same as it looking up for an app with dynamic numbers
    of threads.


   Cliff Woolley
   Charlottesville, VA

View raw message