> > > Wait a second, our user configured the server so that the child process
> > > never terminates.  That's what our docs say that directive does.  This
> > > says, well, we just take a really long time to terminate.  Either the
> > > patch needs to be backed out, or the docs need to change.  I personally
> > > would rather keep the 0 meaning the child process never dies.
> >
> > I should clarify quickly, I have stated a preference, but I will be
> > perfectly happy as long as either the docs change or the code does.
> >
>
> Dude...think about it in practical terms for a sec.  How long will it
> take for a given process to server 2G requests?  and what bad thing will
> the admin notice?
>
> (i.e. why bother?)

It depends on how busy they are, and how many threads they have configured
for the site.  But, the reason for why bother, is that we should respect
our users enough to tell them the truth.  The fact is that what we
implement right now is different from what our docs say.  I am simply
asking that we either do what our docs say, or fix the docs.

People do some pretty strange things with Apache.  What about somebody who
creates an embedded version of Apache, using ONE_PROCESS mode, and
MaxRequestsPerChild == 0.  After a quick grep of the prefork MPM, it looks
like we die if our single process hits MaxRequestsPerChild.  That means
that at some point six years from now, that embedded device will die.

Also, changing the docs will tell new developers exactly how things work.
This way, they won't be trying to figure it out.  Also, take a look at the
e-mail from yesterday.  The only thing we know about MAX_INT, is that it
is >- 32768.  This means that on some older platforms (A/UX?) may have
much smaller values for MAX_INT.  Documentation can solve that problem.

Finally, I am -1 for this patch completely, unless it is propogated to all
of the other MPMs.  Our MPMs already differ too much with regard to how
they handle the same directive.

Ryan


_______________________________________________________________________________
Ryan Bloom                              [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------



Reply via email to