> > Consider the case where an admin configures the server to listen on > > www.foo.com:8080, but he never assigns a child process to listen to that > > port. If you just don't accept the connections, the user will hang > > forever. If every child process, however, actively closes the sockets > > that it can't serve, then the client won't even be able to connect. > > That's a good point too. > > > > What I was thinking was to add an artificial limitation that you can't > > > share an IP:port pair across two different uid/gid's since that's the > > > only case you want to pass a connection. > > > > That limitation should already exist, although it may not. > > That limitation doesn't exist either in the documentation or in the > implementation. > > I figured that was part of the point of connection passing. I know it's > also useful for passing between the siblings for a particular uid/gid > also, but why not just require 1 child per uid/gid and then not worry > about connection passing at all?
A couple of reasons. Remember first of all that the more threads per process, the less stable your server. This is because if a module seg-faults, the whole process dies. For that reason, many admins will want to have multiple child processes with the same uid/gid to create some failover. The second reason, however, is that the file descriptor passing is meant to solve the case of multiple Name-based Vhosts on the same ip:port all with different uid/gid requirements. In that case, you will have multiple child processes all listening to the same ip:port, but you will need to do the file descriptor passing. Closing the file descriptors of ip:port combinations that can't be served is a great optimization, but that is all it is, an optimization for the non-Name-based vhost case. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
