config handling (was: Re: cvs commit: httpd-2.0/server core.c)

[Greg Stein <gs...@lyra.org>]

On Sat, May 18, 2002 at 12:32:20PM -0500, William A. Rowe, Jr. wrote:
>...
> Ok, segfault  is gone.  So is some validation that ServerRoot occured in a 
> global
> context.  Actually, that means that LoadModule and others are not tested to be
> in the global context either.

(see further below)

>...
> I'm just getting my head wrapped around cfg parsing, so anyone with a whole
> lot more background here might be able to provide pointers.  Notice that we
> can't defer ServerRoot processing unless we defer LoadModule processing.

EXEC_ON_READ is *ONLY* intended to be used for things like LoadModule.
Essentially, LoadModule needs to be executed right away so that we can
properly *parse* the rest of the file.

Outside of the initial parse into the configuration tree, and whatever is
needed to build that tree, NOTHING should ever be EXEC_ON_READ. I know that
some things have gotten a bit sloppy with that, but I've never had the time
or inclination to go and do a review.

Once you get the tree loaded, then you should be able to simply scan it for
the validation. You should be able to detect an improperly positioned
ServerRoot just by looking at the tree.

Note that the ideal config parse/load looks like:

1) process the config, constructing the tree. invoke any EXEC_ON_READ
   directives, as these are required to complete this step

2) process the tree to find logging directives and execute them
   [ these might be EXEC_ON_READ today, which would be abdness ]

3) process the tree for all the directives, now that logging is available

Note that we really only need to hit the file once to parse the tree. The
logic was never completed for this, however, so we actually read/parse the
tree twice.

> If we REALLY get a better handle on this, I see no reason to maintain the
> test-load then re-load configuration logic.  If we can pre-process what we must
> with EXEC_ON_READ, then open logs and the like, we should be able to
> directly proceed to run_mpm, without dumping it all and reloading.

Yup.

> On Win32, we load-unload-reload the parent, then load-unload-reload the child
> config.  Losing both redundant unload-load sequences will be a huge win at
> startup.

Yup. If we process the tree in a much smarter fashion, then nothing should
need to be unloaded.

>...

Regarding the first question, about validating ServerRoot. As I mentioned
above, you can go do the validation during the second pass. Of course, that
means that it was a bit "late". It may be possible to build in some flags
that say "this directive can only occur at the top level". When the parser
sees a directive with that flag set, and it isn't at the top level, then it
would simply barf it up.

[ I think the "only at top level" makes a lot more sense than the flags we
  have nowadays. the current flags are a confusing much of where a directive
  can or can't appear; the names are bad, the combinations aren't clear, and
  even the symbols aren't properly namespace (e.g. OR_LIMIT) ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: config handling (was: Re: cvs commit: httpd-2.0/server core.c)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 07:31 PM 5/20/2002, Scott Hess wrote:
>On Mon, 20 May 2002, Greg Stein wrote:
> > On Sat, May 18, 2002 at 12:32:20PM -0500, William A. Rowe, Jr. wrote:
> > > On Win32, we load-unload-reload the parent, then load-unload-reload
> > > the child config.  Losing both redundant unload-load sequences will
> > > be a huge win at startup.
> >
> > Yup. If we process the tree in a much smarter fashion, then nothing
> > should need to be unloaded.
>
>One thing I _like_ about the load-unload-reload is that it generally
>forces you (the module author) to consider the graceful restart case,
>rather than simply crashing (or getting buggy) the first time someone does
>it.  [Sorry if you're using those terms in a technical fashion that I'm
>not following.]

As much as I agree, a wise soul recently pointed out to me, offline, that
if a module author doesn't test the graceful restart case, that's their
foolishness, everyone shouldn't have to pay for it once [or twice] per
startup :-)

>OTOH, on Windows the parent and child both have to load things, so you get
>a similar effect.

Not really.  It is a nasty effect, but entirely dissimilar :-)

>[Speaking of this, one thing I'd like to see for Windows would be a way
>for the parent process to cache the config (or parse tree) and pass it
>directly to the child, so that you don't have the possibility of changing
>config when a new child is spawned due to MaxRequestsPerChild.  Yeah, I
>_should_ submit a patch rather than a request.]

We tossed about the idea of passing all pool_userdata from conf pool to
the child conf pool.  Dunno if that's the right solution.

But given all the new inheritance we deployed in the winnt mpm, it would
be really nice to make that all accessible to mod_log_config, and it's
cousins, and even more distant relatives such as SSL keys.

Bill

Re: config handling (was: Re: cvs commit: httpd-2.0/server core.c)

[Scott Hess <sc...@avantgo.com>]

On Mon, 20 May 2002, Greg Stein wrote:
> On Sat, May 18, 2002 at 12:32:20PM -0500, William A. Rowe, Jr. wrote:
> > On Win32, we load-unload-reload the parent, then load-unload-reload 
> > the child config.  Losing both redundant unload-load sequences will 
> > be a huge win at startup.
> 
> Yup. If we process the tree in a much smarter fashion, then nothing
> should need to be unloaded.

One thing I _like_ about the load-unload-reload is that it generally
forces you (the module author) to consider the graceful restart case,
rather than simply crashing (or getting buggy) the first time someone does
it.  [Sorry if you're using those terms in a technical fashion that I'm
not following.]

OTOH, on Windows the parent and child both have to load things, so you get
a similar effect.

[Speaking of this, one thing I'd like to see for Windows would be a way
for the parent process to cache the config (or parse tree) and pass it
directly to the child, so that you don't have the possibility of changing
config when a new child is spawned due to MaxRequestsPerChild.  Yeah, I
_should_ submit a patch rather than a request.]

Later,
scott