httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: MPM re-write for network logic
Date Tue, 13 Nov 2001 03:55:27 GMT
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 :-)


> 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
> Covalent Technologies
> --------------------------------------------------------------

View raw message