httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: How does MPM actually work?
Date Fri, 03 Dec 2004 23:50:02 GMT
On Fri, 03 Dec 2004 18:07:12 -0500, Ronald Park <> wrote:
> And, given the problem described about long running request causing
> children to potentially fall off the scoreboard, what happens in the
> following scenario:
> Each of the X servers has 1 or more threads working on loooong requests.
> Other threads in each of those servers finish off M requests, meeting
> (or exceeding?) MaxRequestsPerChild.  (BTW, could you explain which
> thread takes on responsibility for nicely shuting down the process?
> The thread which pushed us past MaxRequestPerChild, the long running
> thread (when it eventually finishes) or some 'master' thread?)

see server/mpm/worker/worker.c; a call to signal_threads() gets
everybody to exit; that can be called in various conditions on
different threads

> Under these circumstances, the X children can't (yet) exit... but
> there's still more requests coming in.  And what happens when the
> listen queue fills up in the parent?

There is no listen queue in the parent.  Incoming connections are
queued only in the kernel before a thread in a child process calls

In this [basket] case, you have MaxClients child processes, each with
one thread processing an active request; there are no listener threads
since the processes are in the act of exiting and the listener thread
exits in that case, so everything queues up in the kernel until the
kernel accept queue overflows.

This is similar in effect to What happens in the more normal
MaxCLients conditions: Listener threads won't exit, but they will
refuse to accept more connections if there is no thread available to
process the connection, so everything queues up in the kernel until
the kernel accept queue overflows.

This, like other MaxClients conditions, ends when a request ends.

View raw message