tickless cron

[Rogelio Serrano]

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?

or "12 60 * * * *" when is the next timeout?

-- 
things i hate about my linux pc:

1. it takes more than a second to boot up
2. keeps asking about filenames and directories
3. does not remember what i was working on yesterday
4. does not remember all the changes i have ever made
5.cannot figure out necessary settings by itself