apache-nspr-03

[Dean Gaudet <dg...@arctic.org>]

http://www.arctic.org/~dgaudet/apache/2.0/apache-nspr-03.tar.gz

Ok this one has a better chance of compiling on win32... and maybe
even running.

I ruthlessly removed #includes of unix system headers.  Then I dealt
with the aftermath... I mostly deleted or #if 0d code.

I removed almost everything in conf.h, because it was pretty much all
unix system call stuff... and that's all hidden by NSPR now.

I dealt with a few XXXs, like converting ap_parseHTTPdate to the NSPR
time types, and updating util_md5.

I started to rip apart the main loop.  I really don't know what thread
dispatching model to use yet.  Right now it spawns a few threads to
start with, and never spawns any more.  The threads acquire a lock before
doing an accept().  The problem here is that the optimal algorithm
depends on a bunch of factors:

    - if it's a native threads version of NSPR or not
    - if the native threads are an MxN model (i.e. solaris) or not
    - how many cpus are in the system
    - how many sockets are in use, and the rate of request arrival at each

I did a first pass at implementing the pool changes Ben Hyde and I talked
about.  Specifically, ap_make_sub_pool(NULL) is no longer valid (and curse
anyone who used it, it shouldn't have ever existed in the first place).
ap_make_root_pool() creates a "thread root pool" ...  which is a root
for a tree of pools which are expected to be used by a single thread.
Each tree has its own freelist (kept to a small size) and as long as
the freelist isn't empty or full the thread doesn't need to acquire
the global alloc mutex.

Performance is still on par with the multiprocess model.  It's slightly
better now, but only slightly.  I expect to see a larger improvement
when I get it into a real test setting... testing across loopback you
really can't see the advantages of threads.

There was another release of mozilla today... so I grabbed that.  This
time I was able to run the pthreads version on linux without a
segfault... and it sucked -- about 80% of the performance of the
user-threads version.  I've a few guesses as to why.  But again, I
gotta get a real testbed before I do any extensive performance
tuning.

Dean