We're currently using rufus-scheduler under the hood to parse and run the schedule. We can be a little more lightweight and increase testability if we replace it.
rufus-scheduler uses a periodically awoken thread to enqueue jobs:
Since we know our full schedules at boot, we can use precise thread sleeps to awaken only when a job actually needs to be enqueued. Use something like https://github.com/siebertm/parse-cron combined with concurrent-ruby's ScheduledTask. Ideally there is just a single "timer" thread that handles all schedules, so the Scheduler object will need to be able to merge any overlapping tasks (ie, don't have a ScheduledTask for each of the schedule's job specs).
There may be issues around clock drift if there are long waits between job executions. It may make sense to have a maximum sleep time so that the Scheduler can wake up and re-sync with the system clock. It's probably safe to have this be much longer than rufus-scheduler's default frequency (0.3 secs), as long as detection of skipped times is included (schedule any tasks missed because of clock drift immediately?).
We're currently using rufus-scheduler under the hood to parse and run the schedule. We can be a little more lightweight and increase testability if we replace it.
rufus-scheduler uses a periodically awoken thread to enqueue jobs:
https://github.com/jmettraux/rufus-scheduler/blob/master/lib/rufus/scheduler.rb#L565
Since we know our full schedules at boot, we can use precise thread sleeps to awaken only when a job actually needs to be enqueued. Use something like https://github.com/siebertm/parse-cron combined with concurrent-ruby's ScheduledTask. Ideally there is just a single "timer" thread that handles all schedules, so the Scheduler object will need to be able to merge any overlapping tasks (ie, don't have a ScheduledTask for each of the schedule's job specs).
There may be issues around clock drift if there are long waits between job executions. It may make sense to have a maximum sleep time so that the Scheduler can wake up and re-sync with the system clock. It's probably safe to have this be much longer than rufus-scheduler's default frequency (0.3 secs), as long as detection of skipped times is included (schedule any tasks missed because of clock drift immediately?).