httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronald Park <r...@cnet.com>
Subject Re: How does MPM actually work?
Date Fri, 03 Dec 2004 23:07:12 GMT
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?)

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?

Thanks,
Ron

On Thu, 2004-12-02 at 11:46 -0500, Jeff Trawick wrote:
> On Thu, 02 Dec 2004 13:01:49 +0000, Scott MacVicar <scottm@spamcop.net> wrote:
> > Hi,
> > 
> > I've been trying to get my head around the MPM module and I realise its
> > a hybrid of multi-threading and multi-processing. Can someone either
> > confirm what I'm saying or correct any obvious mistakes.
> > 
> > 1 Main httpd process
> 
> call this the parent process
> 
> > X server processes
> 
> call this the child processes
> 
> > Y child threads
> > 
> > the main httpd process handles the socket connections which passes it to
> > one of the server processes and once its been processed there any data
> > to be sent back to the client is handled by one of the child threads?
> 
> parent process does not handle connections; it sets up the listening
> sockets at initialization, but only child processes will accept new
> connections
> 
> > If so how do you pass data between the different processes, pipes or
> > shared memory?
> 
> not done
> 
> (caveat: perchild is a special beast that sends file descriptors over
> unix sockets from one child process to another; it is just an
> experiment and its behavior shouldn't confuse the issue)
> 
> > I read about the various directives for the mpm module and had a look
> > through the code but I'm just trying to get a better understanding. If
> > there is a document somewhere that I've missed that explains this then
> > apologies.
> 
> take worker MPM, for example
> 
> each child process has a thread that listens for new connections; when
> it gets one, it uses apr_thread_cond*() APIs to dispatch a worker
> thread to handle that connection
-- 
Ronald Park <ronp@cnet.com>


Mime
View raw message