⚡️cron: arm a one-shot timer for the next job instead of polling at 1 Hz#1659
Merged
Conversation
Coral-coder
changed the title
jplexer
force-pushed
the
pr/cron-one-shot
branch
from
July 16, 2026 13:34
f3638d3 to
169fb37
Compare
jplexer
force-pushed
the
pr/cron-one-shot
branch
from
July 16, 2026 14:48
169fb37 to
94829ff
Compare
The cron service registered a per-second regular_timer callback that locked the job-list mutex and compared the head job's execute time against the clock 86400 times a day, almost always concluding there was nothing to do. Cron already knows exactly when the next job is due, so arm a one-shot new_timer for that instant instead and re-arm on every list mutation (schedule, schedule_after, unschedule, clear) and firing. Job execution semantics are unchanged: callbacks still run on the timer task at the same second they used to, offset_seconds resolution is preserved, and cron_service_handle_clock_change() still runs due jobs and now re-arms for the new head. The armed interval is capped at one hour so any tick-clock drift across long sleeps stays bounded. Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: GPT-5 <noreply@openai.com> Signed-off-by: Ara Michelle <coral-coder@proton.me> (cherry picked from commit 90a67da) Signed-off-by: Joshua Jun <lets@throw.rocks>
jplexer
force-pushed
the
pr/cron-one-shot
branch
from
July 16, 2026 15:03
94829ff to
93147f7
Compare
gmarull
approved these changes
Jul 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The cron service registered a per-second regular_timer callback that locked the job-list mutex and compared the head job's execute time against the clock 86400 times a day, almost always concluding there was nothing to do. Cron already knows exactly when the next job is due, so arm a one-shot new_timer for that instant instead and re-arm on every list mutation (schedule, schedule_after, unschedule, clear) and firing.
Job execution semantics are unchanged: callbacks still run on the timer task at the same second they used to, offset_seconds resolution is preserved, and cron_service_handle_clock_change() still runs due jobs and now re-arms for the new head. The armed interval is capped at one hour so any tick-clock drift across long sleeps stays bounded.
(cherry picked from commit 90a67da)