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()
> {
> #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
> }
>
This isn't even close to optimal. Here are just a few issues to think
about:
(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
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
