On Mon, Oct 21, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > 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.
Well, that's what I said before, but you implied that the limitations should prevent this. :) > 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. Yes. This brings it back to what I was saying before, you can't pass SSL connections, so as a result, you can't share an SSL port across two uid/gid's. So this should be documented somewhere, or enforced in the server (which may be difficult because of the layering), so people don't do that :) Anyway, I think I understand the path to follow now. I'm going to implement the necessary fixes to make perchild finally usable. JE
