httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject MPM re-write for network logic
Date Tue, 13 Nov 2001 02:55:43 GMT


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

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

View raw message