Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <011501c16bf7$0b53f3f0$01000100@sashimi>
From: "Bill Stoddard" <bill@wstoddard.com>
To: <dev@httpd.apache.org>, <rbb@covalent.net>
References: <20011113025544.2AA4746DFD@koj.rkbloom.net>
Subject: Re: MPM re-write for network logic
Date: Mon, 12 Nov 2001 22:55:27 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I need to study your proposal in detail... but for now I'll try to plant a seed...

Now seems to be a good time to consider what an async event driven network API would look
like :-)

The worker and windows MPM architectures lend themselves to this. One (or more) thread
doing accepting; multiple workers blocked on a queue (completion port, pthread condition
varible, kqueue, /dev/poll, etc). Hopefully should be simple extension to do
non-blocking/async reads and writes and have the completion status posted to the same
queue the worker threads are blocked on :-)

Bill

>
> Grrrrrrrrrr.........
>
> MPMs suck sometimes.   :-)
>
> I am trying to remove the network logic from the MPMs, so that modules can
> implement different transport layers.  I am looking at using a couple of hooks to
> accomplish this.  The problem is that Windows just doesn't fit into this model at
> all.
>
> Every other MPM fits a simple model.  The child process starts and it creates an
> apr_pollfd_t with every socket.  If there are multiple sockets, then the MPM
> calls apr_poll.  It then takes the socket and calls apr_accept. The socket is
> then passed to ap_run_create_connection, and the server can process
> the socket.
>
> This model suggests the following flow to solve the problem.
>
> 1)  a hook to add items to poll set
> 2)  the MPM calls apr_poll
> 3)  a hook to accept the connection and pass the information
>      to ap_run_create_connection.
>
> The only problem I have with this, is that it requires that every transport layer
> can be represented as the same primitive as a socket.  I don't think this is an
> issue, because on Unix and Unix-like platforms, this will be an int, and on
> Windows, this will be a Handle.  OS/2 might have a problem, because it uses
> SOCKET, which is not generic at all.
>
> I thought of having a hook to replace the call to apr_poll, but I couldn't get
> past the starvation problem that always resulted.
>
> The problem that remains is Windows.  Windows starts the server, and creates
> one thread for each socket that is configured.  That thread sits in accept, and
> passes the accepted socket to worker threads.  This seems like a waste of
> resources, but I will accept that the Windows experts know what they are doing.
> My problem is that it doesn't really fit the model above. I guess that Windows
> could work by using the first hook above, and then looping through the
> apr_pollfd_t, creating threads that call the third hook above.
>
> How does this sound to everybody?
>
> Ryan
>
> ______________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> --------------------------------------------------------------
>