Skip to content

Allow overriding Timer's drift-warning threshold#78

Open
wbarnha wants to merge 1 commit into
masterfrom
claude/issue-46-timer-drift
Open

Allow overriding Timer's drift-warning threshold#78
wbarnha wants to merge 1 commit into
masterfrom
claude/issue-46-timer-drift

Conversation

@wbarnha

@wbarnha wbarnha commented Jul 19, 2026

Copy link
Copy Markdown
Member

Description

Fixes #46.

Timer.max_drift was always auto-computed as min(interval_s * 0.30, 1.2s), with no way for a caller to configure it. For ServiceThread's internal 1s keepalive timer specifically, this meant any app with slightly bursty scheduling would get Timer ... woke up too late log spam at the default INFO level with no way to raise the threshold short of monkeypatching mode.timers module constants — exactly the issue's complaint.

Changes

  • Timer.__init__ gains an optional max_drift parameter, defaulting to None (preserves the existing auto-computed heuristic exactly, no behavior change for existing callers).
  • Service.itertimer() threads max_drift through so any timer a Service starts can override it.
  • ServiceThread gains a keepalive_max_drift class attribute (default None, same auto-computed behavior) that flows into the internal _thread_keepalive timer specifically — subclasses or instances can now set it directly instead of touching module globals.

Verification

  • Added tests: the default heuristic is unchanged when max_drift is omitted; an explicit higher max_drift suppresses a drift that would otherwise warn (both early and late); an explicit lower max_drift makes a normally-silent drift warn, proving the override works in both directions, not just as a one-way "quiet down" escape hatch; and ServiceThread.keepalive_max_drift is correctly forwarded to itertimer.
  • Full suite: 747 passed on Python 3.11 and 3.13, ruff clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HgnKFtXZbCjXNoVNWa5JLd


Generated by Claude Code

Timer.max_drift was always auto-computed as
min(interval_s * 0.30, 1.2s), with no way for a caller to configure it.
For ServiceThread's internal 1s keepalive timer specifically, this meant
any app with slightly bursty scheduling would get "Timer ... woke up too
late" log spam at the default INFO level with no way to raise the
threshold short of monkeypatching mode.timers module constants.

Add an optional `max_drift` parameter to Timer.__init__, defaulting to
None (preserves the existing auto-computed heuristic exactly). Thread it
through Service.itertimer() so any timer a Service starts can override it.
Add a `keepalive_max_drift` class attribute to ServiceThread (default
None, same auto-computed behavior) that flows into the internal keepalive
timer specifically, since that's the timer the issue is actually about --
subclasses or instances can now set it directly instead of needing to
touch module globals.

Tests cover: the default heuristic is unchanged when max_drift is
omitted; an explicit higher max_drift suppresses a drift that would
otherwise warn (both early and late); an explicit lower max_drift makes a
normally-silent drift warn (proving the override works in both
directions, not just as a one-way "quiet down" escape hatch); and
ServiceThread.keepalive_max_drift is correctly forwarded to itertimer.

Assisted-by: Claude
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HgnKFtXZbCjXNoVNWa5JLd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

_thread_keepalive spams to much with timer logs

2 participants