On 22 Nov 2010, at 2:45 PM, Jeff Trawick 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?
I'd say definitely a problem worth solving, if only for the elimination of nasty edge cases. The solution sounds sensible.
Regards, Graham --
