> -----Ursprüngliche Nachricht----- > Von: Graham Leggett > Gesendet: Mittwoch, 26. März 2008 16:56 > An: dev@httpd.apache.org > Betreff: Proposal: a "cron" interface for httpd > > 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?
What data do you supply to the hooks? What if the execution of the hook takes longer then the defined frequency of this hook? Regards Rüdiger
