4 ms·
This appears to have no syntax for X minutes past the hour, and the like. Even more than cron, this would encourage writing a thundering horde of jobs that all
by bazzargh 14y ago
This appears to have no syntax for X minutes past the hour, and the like. Even more than cron, this would encourage writing a thundering horde of jobs that all trigger at midnight?
Cron's syntax lets you easily calculate the next time a job will have to be run (rather than eg re-checking schedules each second, as in the earliest crons). However, exact timing isn't always necessary or desirable - eg in this case, encouraging all users to run jobs at exactly the same time.
I wonder if there is room in the plethora of cron alternatives for one whose syntax encouraged users to schedule jobs eg 'overnight' and left it up to a scheduler to spread jobs evenly? So eg, 'every hour' actually meant 45-75 minutes between executions.
Something similar happened with g_timeout_add_seconds and tickless idle; there the idea was to gather scheduled events to clock second boundaries, to avoid cpu wakeups-because really, users didn't care that they needed the timer to run exactly n seconds from now.
- barkmadley 14y agoYou can implement crons level of timing specificity with a few "every" jobs and some variables. e.g. (not real syntax) every minute: set minute = (minute + 1) % 60 when minute = 4 && day = 5 ... I think the better part of this system is the cascading success semantics that it would provide, where by a next stage doesn't start if the previous stage didn't finish successfully. This has a lot of overlap with Jenkins and other CI servers, but without the java/http overhead and with a (potentially) lighter weight text based syntax for specifying the dependencies between jobs. I can even envision this sort of system to be used to distribute jobs to slave machines given a small amount of ssh foo.