httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <>
Subject Re: configuration directives redux
Date Thu, 03 Aug 2006 22:50:15 GMT
Hi --

>    Some time ago, I proposed this large patchset (better described,
> I think, by the message referenced by the second link below):
>    Discussing the issues on IRC, I received a few responses, including
> a long one from William A. Rowe, Jr.  His main point, I believe,
> was that the order of configuration directives in the tree should
> never be altered from what it is in the configuration files.  Therefore,
> what the worker and event MPMs do now in their pre_config stages --
> namely, re-ordering ThreadsPerChild ahead of MaxClients -- should not
> be done.  Instead, all such order-dependent configuration directive
> checking should be done in a post-config phase, either open_logs or
> post_config.

   Well, as promised (threatened?), here are a complete set of patches,
I believe:

   I thought I'd wait a few days and see if objections were raised,
then commit at least the prefork, worker, and event MPM ones, which
I've tested quite extensively.

   The patches for the other four platforms (winnt, netware, beos,
and mpmt_os2) I have no way of testing.  If anyone with access
to one or more of those platforms could test and review, that would
be greatly appreciated!

   Of those, the Windows one is the one I'd particularly like someone
to test and review.  It has two key differences from the others:

a) Like the prefork, worker, and event MPMs, there are ordering
   issues involved -- the bounds checks on ap_threads_per_child
   need to occur after the bounds checks on thread_limit.  The
   existing code, I believe, has the same problem that exists
   with the worker and event MPMs:

   > [I]f ThreadsPerChild was not
   > specified at all, then the default value of DEFAULT_THREADS_PER_CHILD
   > could potentially be larger than the configured ThreadLimit,
   > and no test would be performed, since set_threads_per_child()
   > would never run.  This could result in an out-of-bounds value
   > for ap_threads_per_child in the running server.

b) Unlike the other MPMs, there seems to need to be some special
   handling with regard to what code runs in the parent.  I've
   attempted to comprehend this without access to a test platform,
   but no doubt I've made some errors.

   So ... anyone for some testing?  Anyone, anyone?

   Also ... objections to committing the patches for the prefork,
worker, and event MPMs?


GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

View raw message