create a pool associated with the MPM generation?

[Jeff Trawick <tr...@gmail.com>]

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?

Re: create a pool associated with the MPM generation?

[Stefan Fritsch <sf...@sfritsch.de>]

On Monday 22 November 2010, Graham Leggett 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.


> > 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.

+1

Re: create a pool associated with the MPM generation?

[Graham Leggett <mi...@sharp.fm>]

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
--

Re: create a pool associated with the MPM generation?

[Jim Jagielski <ji...@jaguNET.com>]

On Nov 22, 2010, at 7:45 AM, 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.
> 

++1...

Re: create a pool associated with the MPM generation?

[Jeff Trawick <tr...@gmail.com>]

On Mon, Nov 22, 2010 at 7:45 AM, Jeff Trawick <tr...@gmail.com> 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?