tickless cron

[Rogelio Serrano]

On 9/6/06, Rob Landley <rob at landley.net> wrote:
> On Tuesday 05 September 2006 1:20 pm, Rogelio Serrano wrote:
> > it is not stupid after all. it can be done as a preprocesss step
> > instead. analyse the cron schedule string and generate a list or array
> > of timeout events for the particular period which can be easily
> > inferred from the schedule string. then all the server needs to to do
> > is walk through the structure. more space will be needed though but i
> > dont mind.
>
> I'm confused.  If you figure out when the next event is, and wait until that
> next event, why do you care about later events yet?  When does a schedule
> string come into it?  Why does figuring out future events later take more CPU
> power than figuring out future events now?  (You have to wake up later to
> handle one event: why not look for the event after that then?)
>

its a matter of preference i think. i dont want a loop running so many
times regularly. i would rather have big structures than loopy code.
updating schedules happen less often then a regular timeout too.

on the other i am testing your suggested solution and its working well.

> What's the advantage of your preprocess step?  It's doing the same amount of

no it averages out to less calculation considering that schedule
updates dont happen regularly. and some schedules just need to happen
at a regular interval and requires a simple add to get the next
timeout.

> calculation, it's just doing it earlier than it needs to and allocating
> unnecessary memory to store the result...
>

not necessarily. schedules have a finite repetition period. so they
can be computed only once.

-- 
the thing i like with my linux pc is that i can sum up my complaints in 5 items