Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: API for detecting first config run
Date: Wed, 2 Feb 2011 21:57:17 +0100
User-Agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; )
References: <201011121947.29350.sf@sfritsch.de>
 <201011142151.24100.sf@sfritsch.de>
 <AANLkTi=j4c+O0t8FHAkGYW97qaiQdaKY9VZW8uMYA6M5@mail.gmail.com>
In-Reply-To: <AANLkTi=j4c+O0t8FHAkGYW97qaiQdaKY9VZW8uMYA6M5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201102022157.18020.sf@sfritsch.de>

On Sunday 14 November 2010, Jeff Trawick wrote:
> On Sun, Nov 14, 2010 at 3:51 PM, Stefan Fritsch <sf@sfritsch.de> 
wrote:
> > On Saturday 13 November 2010, Jeff Trawick wrote:
> >> >> which questions should modules be able to ask?
> >> >> 
> >> >> last-load/init-before-activation?          (seems to work for
> >> >> most purposes)
> >> > 
> >> > Yes, that's what I meant: Will the current config be actually
> >> > used to process requests?
> >> > 
> >> >> pre-detach-load/init?     (never seen when added during
> >> >> restart) (not to mention weird Windows stuff -- is this the
> >> >> parent or the child, and which pass)
> >> > 
> >> > Is this something that modules need to be aware of? Usually
> >> > it's just that the module needs to do something
> >> > time-consuming, but only wants to do it for the config that
> >> > is actually used for requests. E.g mod_rewrite will skip
> >> > spawning the rewrite map children during the first config
> >> > run, and mod_php will skip initializing its interpreter. If
> >> > there are modules that need more specific information, the
> >> > new API should probably provide that. But I am not aware of
> >> > any such modules.
> >> 
> >> anything that prompts the user for passphrase or wants to issue
> >> a warning message cares about pre-detach
> >> 
> >> I'm not sure about awareness of the Windows oddity; my vague
> >> understanding is that a lot of modules perform wasted init in
> >> the Windows parent.  If was important to know, how would the
> >> module check?
> >> 
> >> >> should pre-config and post-config just get an indicator?
> >> > 
> >> > I am not sure what you mean here.
> >> 
> >> sorry; "other parameter(s) to those hooks to tell them the
> >> server state" (but modifying the parameter lists is an
> >> aggravating migration step)
> > 
> > No, that's too intrusive. Right now I think the following would
> > be best:
> > 
> > - Adding new query codes to ap_mpm_query as necessary, starting
> > with AP_MPMQ_STARTUP_STATE_FINAL_CONFIG
> > - Giving the MPM a way to check if we are in the first config run
> > on startup by setting some global variable in main.c, adding a
> > note that normal modules should use ap_mpm_query instead of the
> > variable.
> > 
> > This way the MPM can influence what is returned and the interface
> > is extensible.
> 
> This particular behavior is not determined or influenced by the
> MPM; it is hard-coded into main()*.  In fact, MPM modules may wish
> to use a new API.  So ap_mpm_query() shouldn't be used for this.
> 
> *perhaps some platform-specific details are elsewhere

I want to come back to this issue. Apart from modules asking the 
question "will this config actually be used for processing requests", 
I would like to have an answer to "are we only testing the config" and 
"are we only dumping some parts of the config".

For example, if we are only dumping some parts of the config, we may 
want to skip asking the user for SSL-key passphrases.

So, I propose to add an extensible API analogous to ap_mpm_query, but 
for the main process. I would maybe just call it ap_state_query(). For 
a start, I would implement two query options:

AP_SQ_MAIN_STATE: This would correspond to which part of main.c is 
currently executing:

	AP_SQ_STARTING
	AP_SQ_CREATE_PRE_CONFIG
	AP_SQ_DESTROY_CONFIG 
	AP_SQ_CREATE_CONFIG
	AP_SQ_RUN_MPM
	AP_SQ_EXITING

The three states AP_SQ_STATE_DESTROY_CONFIG, ..., AP_SQ_STATE_RUN_MPM 
would repeat after every graceful restart.
                
AP_SQ_RUN_MODE: This would allow to find out if some config dump was 
requested (without having to know the names of all DUMP_* defines):

	AP_SQ_CONFIG_TEST
	AP_SQ_CONFIG_DUMP
	AP_SQ_SERVE_REQUESTS


Any comments? Ideas for better names?