httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Erdfelt <>
Subject Re: [patch] perchild MPM bug fixes (+ open problem)
Date Mon, 21 Oct 2002 18:03:55 GMT
On Mon, Oct 21, 2002, <> wrote:
> On Mon, 21 Oct 2002, Johannes Erdfelt wrote:
> > 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?
> Yes, it is needed.  The thing is, that you can have multiple child
> processes running as a single user/group combination.  All of those child
> processes will use the same unix domain socket for their
> communication.  So, the thundering herd problem still exists.  If you
> really wanted to optimize this, you could do only lock the file if it was
> configured for multiple child processes, but that is not going to be
> trivial, because that information doesn't really exist at the point that
> you are doing the lock.

Ahh, good point, I forgot about that.

> As long as you are doing all this work, there is one more thought that I
> have been meaning to implement, but that I never got around to.  Currently
> perchild doesn't work with SSL, because of when the request is passed off,
> and how SSL works.  The easy solution to this, is to have the child
> processes close the sockets for any requests that they cannot
> handle.  This will also improve the chance that a request won't be passed
> if you have vhosts with different ports.  Consider the following:
> <VHost>
>     AssignChildPerUidGid  rbb rbb
> </Vhost>
> <Vhost>
>     AssignChildPerUidGid  foo foo
> </VHost>
> There is no reason for the foo/foo child process to be listening on port
> 80.
> Just a thought for how to get SSL to work.

I actually have a patch for this already :) Although I implemented it
only as an optimization and not because of the issue with SSL. I hadn't
tried to do SSL yet.

I'd imagine this SSL limitation will have to be clearly documented since
it may not be obvious to everyone.


View raw message