docs: clarify timer execution order after libuv 1.45.0#99
Conversation
Explain that timers now run after poll in each event loop iteration, while libuv still runs timers once before uv_run() for UV_RUN_DEFAULT to preserve backwards compatibility.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryLow Risk Overview The revised text states that per iteration, timers now run after poll, whereas they used to run before poll, and adds that 1.45.0 still runs timers once before entering the event loop for backwards compatibility. The existing warning about Reviewed by Cursor Bugbot for commit 57df605. Bugbot is set up for automated code reviews on this repo. Configure here. |
👋 Codeowner Review RequestThe following codeowners have been identified for the changed files: Team reviewers: @nodejs/timers Please review the changes when you have a chance. Thank you! 🙏 |
There was a problem hiding this comment.
Pull request overview
Updates the event-loop documentation to more precisely describe how libuv 1.45.0 changed timer execution order, avoiding the misleading implication that older libuv versions ran timers twice per normal UV_RUN_DEFAULT loop iteration.
Changes:
- Clarifies that, starting with libuv 1.45.0, timers run after the poll phase in each iteration.
- Clarifies that earlier versions ran timers before polling in the normal per-iteration path.
- Notes the compatibility behavior in libuv 1.45.0: a one-time timer run before entering the main
uv_run()loop.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| **poll** phase in each event loop iteration. In earlier versions, timers | ||
| were run before polling. To preserve backwards compatibility, libuv | ||
| 1.45.0 still runs timers once before entering the event loop . This change can affect the timing of | ||
| `setImmediate()` callbacks and how they interact with timers in certain | ||
| scenarios. |
The previous wording said that timers now run only after the
pollphase,"instead of both before and after" as in earlier versions. That phrasing can
be misleading because it sounds like earlier libuv versions ran timers twice
during a normal event loop iteration: once before polling and once after
polling.
Looking at the actual libuv code, the behavior is more precise:
Before libuv 1.45.0, the regular
UV_RUN_DEFAULTpath ran timers near thebeginning of each loop iteration, before polling:
There was a post-poll timer run only for the UV_RUN_ONCE special case, not for
the normal UV_RUN_DEFAULT path used by Node.js' main event loop.
Starting with libuv 1.45.0, the regular per-iteration timer processing was
moved to after polling:
libuv 1.45.0 also keeps a compatibility behavior for UV_RUN_DEFAULT: it runs
timers once before entering the uv_run() loop. This preserves backwards
compatibility while still making the per-iteration timer ordering happen after
the poll phase.