[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Something else to think about...
... should've known better than to start talkin' without doing my homework.
A thought for your consideration... the architecture I mentioned earlier
(a single thread to handle requests, multiple threads to service them) will
probably function better in a server context than multiple threads
performing only one function per thread. While I like the abstraction
(although I still think the reader thread is unnecessary), it seems to me
there's a major problem; you've a condition variable at each point in your
transition from function to function. That's unnecessarily expensive...
the architecture I outlind requires only a mutex around what's shared (some
data type which stores file descriptors that the "worker" threads can
gobble up) and a condition variable to wake up threads when requests enter.
But we can do even better... and I'm ashamed for not thinking of it
sooner... :)
Wby not go with the idea of a single thread doing everything... basically
replacing the processes in the current Apache implementation with threads?
Okay, so that's a simplification, but you get the point... we slap a mutex
around accept(), which is performed within each thread, thereby removing
the need for a _single_ condition variable, and watch performance
skyrocket. Even more importantly, from a correctness standpoint (which is
higher up on our priority list :) ), we remove the single-entry-point
dependency inherent in both the designs mentioned thus far; if a
single-thread fails, so long as it doesn't have the mutex, we continue to
function and the error can be cleaned up.
The question remains... how does the _type_ of threading used impact this
discussion? To some degree, it doesn't matter... if we're designing an
even remotely portable Web server, we don't have much say in the matter. A
possible course of action, however, would be to modify NSPR as was
discussed earlier, allowing the library to maintain a pool of threads if
that was the most efficient implementation on the current OS. I _very_
much like the idea of abstracting those decisions from the application...
and I'm sure Netscape would to! :)
Comments?
- Bret -