On Thu, Nov 29, 2001 at 09:20:48AM -0800, Brian Pane wrote:
> From a performance perspective, the two limitations that I see in
> the current worker implementation are:
> * We're basically guaranteed to have to do an extra context switch on
> each connection, in order to pass the connection from the listener
> thread to a worker thread.
> * The passing of a pool from listener to worker makes it very tricky
> to optimize away all the mutexes within the pools.
IIRC, the problem isn't so much the fact that pools may be passed around,
since in that respect they are already threadsafe without mutexes
(at least in the current CVS and in the recent "time-space tradeoff"
patch. I believe the actual problem as you have described it to me is
how destroying a pool requires that the parent be locked. Perhaps you
can better characterize the problem.
> So...please forgive me if this has already been considered and dismissed
> a long time ago, but...why can't the listener and worker be the same thread?
>
> I'm thinking of a design like this:
>
> * There's no dedicated listener thread.
>
> * Each worker thread does this:
> while (!time to shut down) {
> wait for another worker to wake me up;
> if (in shutdown) {
> exit this thread;
> }
> accept on listen mutex or pipe of death;
> if (pipe of death triggered) {
> set "in shutdown" flag;
> wake up all the other workers;
> exit this thread;
> }
> else {
> pick another worker and wake it up;
> handle the connection that I just accepted;
> }
> }
Not a bad idea. Kind of a hybrid between threaded and worker. One
thing I'd be concerned about is the reliability of condition variable
signal delivery. Can we guarantee that one generated signal is caught
by one-and-only-one worker? What happens if none of the workers are able
to catch the signal, is the "token" dropped? The queue might have to
maintain that state if it becomes empty, but I think it's doable.
[/tangent]
I do agree that the next step in optimizing any threaded MPM is to
reduce the number of necessary context switches. As for a Solaris-
specific implementation, one thing that I've been meaning to implement
for a long time is an MPM based on doors. Doors would allow us to have a
listener process that delegates out connections to child processes that
have managed pools of threads. There are quite a few advantages to this
model, the first being that door calls can transfer kthread assignment
in mid-quantum _across processes_. We can also manage a very high level
of performance feedback from each of the child processes through door
calls (ie. calls to report on various resource metrics) so we can better
distribute the load. The unfortunate thing about this model would be that
it is Solaris specific, but having a killer-app for doors might encourage
other kernel developers to implement it (there are some patches around
for doors on linux, for example). Thoughts? I would target this more
long-term, like httpd-2.1 perhaps?
-aaron
