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?
Regards,
Graham
In general that would be helpful, e.g. mod_jk needs to check for idle
connections to close them, and this check is decoupled from request
processing. I guess the same could be true for dbd.
Of course things get harder, if you want to provide timing guarantee to
the modules using the hooks. You might end up using a thread per module
and used hook in order to minimize interference of long running methods
with the hook timing.
Regards,
Rainer
