tickless cron

Rob Landley rob at landley.net
Wed Sep 6 15:12:02 UTC 2006


On Wednesday 06 September 2006 12:36 am, Rogelio Serrano wrote:
> 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.

It's the same number of total trips through the loop either way, and it 
doesn't require any additional wakeups either.  But my solution actually does 
_less_ work than yours, because it doesn't do the extra allocate/free pairs.

> 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.

How does it wind up doing less calculation?  Are there any schedule slots you 
check under only one of the two?  Are any positions checked more than once?

I could be wrong on this one, but I'd like you to explain it to me if so...

> and some schedules just need to happen 
> at a regular interval and requires a simple add to get the next
> timeout.

If cron has to handle an event, cron has to wake up anyway.  When cron wakes 
up anyway, after it handles the event it needs to go back to sleep.  In order 
to go back to sleep, it has to know how long that sleep should last, and THAT 
is the point at which it makes sense to figure out when the next event is: 
right before going back to sleep.  That's the only point in the code that 
actually cares.

> > 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.

Actually rather than doing the one second thing it sounds like the easy way is 
to look at each rule and figure out when it triggers next.  That's bounded.  
(It also leaves open the possibility of having an empty ruleset.)

But I'm not particularly interested in arguing about cron because I don't use 
it and this conversation has not generated a patch, so I'm going to stop now.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list