On Sun, Nov 14, 2010 at 3:51 PM, Stefan Fritsch <[email protected]> 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
