httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: How does MPM actually work?
Date Thu, 02 Dec 2004 16:46:55 GMT
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

Mime
View raw message