On Mon, Nov 22, 2010 at 7:45 AM, Jeff Trawick <[email protected]> wrote: > The purpose of the pool would be the allocation in the parent of > resources which must live as long as any child processes from a > certain generation are still running. It helps bridge the gap between > pconf and the process pool when dealing with graceful restart. > > Each MPM would be responsible for destroying the pool once the last > child of the corresponding generation has exited. Since graceful > restart can be invoked again before all the children of older > generations have exited, there could be an arbitrary number of > generation pools at a given time. > > It might not be trivial to implement, but it would be a huge help for > modules faced with this issue; it is not practical for modules to try > to solve this lifetime issue. > > main() owns the generation ("for (;;) {") and would create the pool. > The natural place to access the pool would be an additional parameter > to hooks which take pconf currently, but that would be disruptive to > almost every module. The mpm hook (implemented by modules which must > be modified anyway) would take a pointer to pgeneration, and an API > call would be provided for other modules to use; the API would only > support access of the current pgeneration; only the MPM would know > about the pool for earlier generations. Each instance of the pool > would be a child of the process pool, created by main(), and destroyed > by the MPM at some arbitrary point later. > > Problem worth solving? > Simpler solution available?
shame on me; with this design, a module needing to run code when the last member of a generation dies would register a cleanup on the generation pool; but in the case of children lingering after graceful restart, a DSO module would have been unloaded and reloaded again by the time the lingering children exit and the generation pool is destroyed, such that the originally registered cleanup function address is now meaningless (MPMs can or do have data retained across unload/load, so the MPM itself isn't the problem) a more obvious trigger mechanism is to register a hook which is called when the last member of a generation dies; that solves the problem of using a cleanup function as the trigger, but leaves the allocation of storage with the proper lifetime to the module; (a generation pool would solve the storage lifetime, but that is an open invitation to the cleanup function issue) possibly I'll find time to experiment with a real graceful restart issues (e.g., mod_cgid daemon lifetime) and see how painful it would be to make use of a hook w/o a pool thoughts?
