On Mar 26, 2008, at 11:55 AM, Graham Leggett wrote:
Hi all,
On a number of occasions recently I have run into the need to run
some kind of garbage collection within httpd, either in a dedicated
process, or a dedicated thread.
Attempts to solve this to date have involved setting up of external
tools to try and solve garbage collection problems, but this is
generally less than ideal, as it amounts to "stuff" that the
potential admin has to configure / get wrong.
Ideally I want httpd to worry about its own garbage collection, I as
an admin don't want it to be my problem.
The interface I had in mind was a set of hooks, as follows:
ap_cron_per_second
ap_cron_per_minute
ap_cron_per_hour
ap_cron_per_day
ap_cron_per_week
It will be up to the relevant MPM to a) create the thread and/or
process that is responsible for calling the hooks, and to actually
call the hooks.
Modules just add a hook as needed, and take it for granted that code
gets run within the limitations of the mechanism.
While not very sophisticated, it works very well with the hook
infrastructure we have now. I am operating on the assumption that
one single thread and/or process running on a server that calls a
possible-empty hook once a second is cheap enough to not be a problem.
Before I code anything up, is this acceptable or are there glaring
holes that I have not foreseen?
Sounds good... Why not have the parent process be the actual cron keeper
and use some method to "signal" the child processes (something pod-like
or maybe a shared memory struct) when something needs to be run?
