httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: [PATCH] convert worker MPM to leader/followers design
Date Thu, 11 Apr 2002 21:25:38 GMT
On Thu, Apr 11, 2002 at 02:09:27PM -0700, Brian Pane wrote:
> The problem isn't that the busy worker threads will never become unbusy
> and pick up new work from the queue.  If the queue is full, and the listener
> is blocked, the listener will (with the current code) be properly awakened
> as soon as one of the workers finishes its current connection.  The problem
> is that it could be a long time before that happens, if all the workers are
> handling very long-lived connections.  And meanwhile, there could be other
> child procs with idle worker threads.

Ok, now we're on the same page. I see this as a problem as well, but I
don't think this is what is causing the problem described earlier in this
thread. Considering how unlikely it is that all of the threads on one
process are on long-lived connections, I don't see this as a critical
short-term problem. What is more likely is that 'ab', used to observe
this phenomon, is flawed in a way that prevents it from truly testing the
concurrent processing capabilities of the worker MPM, when it is possible
for a request on a different socket to be returned sooner than another.
Flood would be much more appropriate for this kind of a test.

> Which all leads me back to the conclusion that we need to stop managing a
> separate queue within each child process.  (In the short term, though,
> blocking the listener from doing an accept if the # of idle workers is
> zero would be a reasonable alternative.)

At one point I had an alternative queue design for worker where slots
in the queue represented an available worker as opposed to now when it
represents an accepted connection. This way when the queue is empty
(or full, depending on how you want to look at it) then there are no
more immediately available worker threads.


View raw message