tickless cron

walter harms wharms at bfs.de
Fri Sep 1 07:48:43 UTC 2006


hi,
i am courious,
setting an timeout will be risky if a task in between takes more time than anticipated
causing an overrun. (think or a datatransfer every 1minute that takes 1.5 minutes).
why should i do it ?

i do not think that you will win much but that. on the other hand if you need it to start
at sunday,11:00 you can use at. what is much better suited for that.

inotify is nice but has changed a lot and is a challenge to support it between
different kernel versions. and frankly stat() is not a bad solution.

re,
 wh





Allan Clark wrote:

>> what i mean is not have cron set a timer to one minute and evaluating
>> all the schedules once a minute. the present crontab format works well
>> in that mode becaue its just a straight comparison with the present
>> time and the values in a crontab line which can actually be placed in
>> a 'struct time'. what i would like to have is for cron to set the
>> timer exactly to the next timeout. i have a tickless kernel and it
>> does not make sense for cron the do exactly what i just removed from
>> the kernel.
>>
>> maybe the crontab compatible schedule just cannot be made to work in
>> tickless mode.
> 
> This "tickless" mode is how the alarmclock tends to work in embedded
> devices, such as linux handsets (mobile phones).
> 
> inotify seems to handle the crontab-changing notion, but might not
> handle when new crontabs are added.  The cron docs say to always use
> "crontab -e", which seems to be a good place to SIGHUP or SIGUSR the
> cron daemon when changes have to be checked.  the crond would also
> need a signal whenever the clock changed (so that "17:00 every sunday"
> still means the same thing) -- that's actually a problem on some
> Alarmclock and scheduler implementations.
> 



More information about the busybox mailing list