Re: configuration directives redux

[Chris Darroch <ch...@pearsoncmg.com>]

Hi --

>    Some time ago, I proposed this large patchset (better described,
> I think, by the message referenced by the second link below):
> 
> http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=114729206702495&w=2
> http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=114788040600327&w=2
> 
>    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:

http://people.apache.org/~chrisd/patches/httpd_mpm_configs/

   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?

Chris.

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

Re: configuration directives redux

[Brad Nicholes <BN...@novell.com>]

>>> On 8/3/2006 at 4:50 PM, in message
<44...@pearsoncmg.com>, Chris
Darroch <ch...@pearsoncmg.com> wrote:
> Hi --
> 
>>    Some time ago, I proposed this large patchset (better described,
>> I think, by the message referenced by the second link below):
>> 
>>
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=114729206702495&w=2

>>
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=114788040600327&w=2

>> 
> 
>    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!
> 

Appears to build and run on NetWare.

Brad

Re: configuration directives redux

[Chris Darroch <ch...@pearsoncmg.com>]

Hi --

>    Well, as promised (threatened?), here are a complete set of patches,
> I believe:
> 
> http://people.apache.org/~chrisd/patches/httpd_mpm_configs/

   I did have one final (I hope) thought last night about this patch.
Currently the prefork, worker, and event MPMs hack their open_logs hook
function into place ahead of the core ap_open_logs() function:

    /* The prefork open_logs phase must run before the core's, or stderr
     * will be redirected to a file, and the messages won't print to the
     * console.
     */ 

   My patches, as written, make all the MPMs do this, which is somewhat
ugly.  One option might be another hook phase that runs after
ap_process_config_tree() and friends, but before both the signal_server
function (prior to entering the main loop) and the open_logs phase.

   My inclination, though, is to add an ap_mpm_post_config
optional function, like ap_signal_server, which gets called just before
it does.  MPMs could register a function that does most or all of
what's in their command handlers now (i.e., what's been moved into
their open_logs handlers in the patches).

   One advantage of adding either the new hook phase or an optional
function is that on restarts, messages can appear on the console
and in the log files, formatted properly for each.  This is difficult
to achieve any other way, I think, for somewhat arcane reasons.

   Personally, I think I favour the optional function -- opinions?
If none, I'll add that to the patches and start committing next
week, barring more late night insights or other roadblocks.

Chris.

P.S.  Thanks, Brad, for the Netware test!

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