httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Proposal: a "cron" interface for httpd
Date Wed, 26 Mar 2008 17:08:04 GMT

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?

View raw message