a module which creates child processes which access the scoreboard must create that child in the pre_mpm hook, since that is the hook where the scoreboard is created (it must be hooked after the core's pre_mpm hook so that the scoreboard has already been created)
but this hook isn't called on graceful restart, so a module doesn't have the opportunity to fork a new child to pick up a changed configuration; the scoreboard itself isn't a problem since it doesn't change, but the module's own configuration changes won't be known and if the module's child process is using ThreadsPerChild or MaxClients or other scoreboard-related values which could be changed across restart, then it is hosed if a module could determine if the server is gracefully restarting, then it could use some combination of post-config and pre-mpm hooks for creating the child process in order to pick up config changes whether or not the scoreboard changes (in post-config hook, if this is graceful restart then replace the old child process with a new one to pick up the new config; otherwise, do that in the pre-mpm hook since we have to wait until the scoreboard is replaced) it seems simpler to pass a flag to pre-mpm hook to tell it whether or not the scoreboard should be replaced; the hook to replace the scoreboard will look at the flag to know when to be a no-op are there other problematic use cases which involve the pre-mpm hook and need to be addressed? any other comments?
