tickless cron

[walter harms]

Rogelio Serrano wrote:
> On 9/1/06, walter harms <wharms at bfs.de> wrote:
>> 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 ?
>>
> 
> you dont understand my question.
> 
>> 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
> 
> tickless kernel does this already.
> 
> the timers are in a sorted list. everytime a new timer is inserted the
> list is sorted and the timer with the closest timeout is chosen.
> 
> my main problem is computing the next timeout given a crontab format
> schedule string.
> 
> for example: given "60 * * * * *" when is the next timeout from now?
> 
that means "every 60 minutes" or when the minute counter == 60 and rest is anything.
(of cause 60m will not work but it does not matter here)

> or "12 60 * * * *" when is the next timeout?
> 
same here read as (minute counter == 12) && (hour counter == 60) && (rest == anything)

complicated are stuff like "next 3. Friday this month". i guess you need to recalculate
everytime you encounter it.

so your basic idea is to calculate the next epoch the command should be executed, and then
recalculated the next epoch every time.

did i get the point now ?

re,
 wh