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. Sounds OK?
