On Mon, Oct 21, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Thu, 17 Oct 2002, Johannes Erdfelt wrote: > > > Ryan, I've CC'd you on this just to let you see the patch. If you don't > > want me to involve you in this, please accept my apologies and let me > > know and I won't CC you in any further patches. > > I have no problem being CC'ed on patches, although for the most part, I am > unlikely to respond. In this case however, I will. I want to say that > this is great. I have reviewed the patch and the logic, and it all looks > fantastic. I'm really glad that the MPM is making progress. I will also > provide a possible solution to the one problem that you were unable to > solve. :-)
Thanks for taking the time to look at the patch. I'll make sure to CC you on any further patches but focus on the rest of the development team to merge it :) > > Problem 4: > > Occasionally, when a request needs to be passed to another process, it will > > hang until another connection is accepted. perchild uses the same process > > accept mutex that the other MPM's seem to need. This results in > > serialization of all accept() calls as is the intent of the mutex. The > > problem is that another process might have acquired the mutex from the > > process that actually needs the mutex to hit accept() and see the passed > > request. This isn't normally a problem because all processes accept > > connections on all listening ports. The problem in this case is the fact > > not all processes accept connections on the per process unix domain socket > > to pass connections around, for obvious reasons. > > > > Solution: > > I don't have one :) I'm not sure what the best way of solving this is. I > > don't fully understand the semantics of the process accept mutex yet. Any > > suggestions? > > There is only one solution that I can see for this, unfortunately, it is a > rather big change. :-( The first step, is to migrate the perchild MPM to > the same model as the worker MPM, where one thread accepts requests and > puts them in a queue, and the rest of the threads remove the requests from > the queue, and actually serve them. I've been meaning to do this for a > long time, but I never got around to it. Ahh, that's a good idea. I can implement this as well. > Once that is done, the solution to this problem is easy. Every child > process needs to have two acceptor threads. The first accepts on the TCP > socket, and the second accepts on the Unix Domain Socket. For the TCP > socket, the thread should just use the same accept_mutex that it is using > now. However for the Unix Domain Socket, each thread that is accepting on > the socket should just use apr_file_lock to lock the socket before > accepting. This should remove the starvation that you are seeing, because > each socket will have it's own lock. If there is only one thread listening on the unix domain socket (because each of those is specific to a child) is a lock even needed? The current lock around the accept() logic is mostly to prevent the thundering hurd syndrome, right? Other than that, this makes perfect sense too, I can implement this as well. Thanks for the reply! JE
