Repository navigation
Make setTimeout and setImmediate timers run consecutively #8460
Description
Continuing from libuv/libuv#1035 (comment):
Node.js uses a uv_idle_t handle to implement setImmediate() timers but I think it could - and should - hang them off the big setTimeout() timer.
Right now you have this weird situation where:
a) setTimeout timers run,
b) some other callbacks run (mostly close callbacks), then
c) setImmediate timers run.
Activity
Fishrock123 commentedon Sep 10, 2016
What are these? Just Immediates or timers scheduled in Immediates?
Immediates should fire after I/O before Timeouts, right?
bnoordhuis commentedon Sep 12, 2016
Immediates.
That's right, the actual callbacks are made from a check handle.
I realize what tripped me up: we call
uv_run(UV_RUN_ONCE)in a loop, causing the big setTimeout timer to run twice per loop tick sometimes.The order of events is approximately: start tick -> timeouts -> I/O -> immediates -> close callbacks -> timeouts again -> end tick.
Trott commentedon Jul 15, 2017
Should this stay open?
If so, @Fishrock123: Are you likely to get to this soon? If not, should we unassign you and/or add
mentor availableandhelp wantedlabels?Fishrock123 commentedon Nov 23, 2017
The
uv_run(UV_RUN_ONCE)part was changed in 9e08695 ... @bnoordhuis any idea if the ordering issues are still present? (Although we may want to make the change regardless.)bnoordhuis commentedon Nov 23, 2017
9e08695 should have fixed the ordering, yes. The issue of timer callbacks and immediate callbacks getting interleaved with other callbacks still exists.
j0t3x commentedon Feb 1, 2018
Is this taken? I would like to work on this one.
apapirovski commentedon Feb 1, 2018
Hi @j0t3x, unfortunately I don't know if there's a clear direction here even... It's a strong possibility that there might be code out there relying on immediates running after I/O.
(For reference http://docs.libuv.org/en/v1.x/design.html)
Also, the fact that setImmediate will run within the same iteration of the loop for everything but close callbacks is IMO a good thing.
j0t3x commentedon Feb 7, 2018
apapirovski commentedon Apr 12, 2018
I've removed the help-wanted label. I'm not sure anyone truly knows what's best here.
I would be in favour of sticking with the current behaviour but of course there is some weirdness associated with it. If we hang them off the timer handle then scheduling them seems to become a bit more problematic — I'm not 100% certain how @bnoordhuis envisions that working, but he also knows libuv a lot better than I so I trust that it's possible in an elegant manner.
bnoordhuis commentedon Apr 12, 2018
How so?
apapirovski commentedon Apr 12, 2018
As far as I can tell they would need to be timers scheduled for 1ms, right? (Scheduling for 0 while in the timer handling process seems to cause those timers to fire again before running the loop again.)
Or is there some other way to hang them off the timer? As I said, only mildly knowledgeable about libuv.
Fishrock123 commentedon Aug 14, 2018
I'm not sure part of this issue exists anymore, since we no longer use
uv_run(UV_RUN_ONCE).Fishrock123 commentedon Aug 14, 2018
Actually, I'm not sure there is an issue at all anymore.
The definition of
setImmediateis, according to the docs:The OP mentions that close handles can fire before immediates after timeouts, but the code of
uv_runseems to indicate that isn't true: https://github.com/libuv/libuv/blob/7284adfa7a833264fc67d68d39610da27ecbab7c/src/unix/core.c#L350-L399The uv loop executes callbacks in the following order each loop:
apapirovski commentedon Oct 26, 2018
This should just be closed at this point. There's nothing actionable here, at least nothing that anyone is realistically willing to do.