Repository navigation
observed setImmediate and setTimeout execution order contradicts documentation #7145
Description
- Version:
v6.2.1 - Platform:
Darwin - Subsystem:
timers
Documentation for setImmediate:
Schedules "immediate" execution of callback after I/O events' callbacks and before timers set by setTimeout and setInterval are triggered.
Demonstration:
console.log("nodejs version", process.versions.node);
console.log("start");
setTimeout(() =>
{
console.log("setTimeout 0 callback");
}, 0);
setTimeout(() =>
{
console.log("setTimeout 1 callback");
}, 1);
setImmediate(() =>
{
console.log("setImmediate callback");
});
setTimeout(() =>
{
console.log("setTimeout 0 after setImmediate callback");
}, 0);
setTimeout(() =>
{
console.log("setTimeout 1 after setImmediate callback");
}, 1);
process.nextTick(() => {
console.log("nextTick callback");
});
console.log("scheduled");Observed outputs:
$ node test.js
nodejs version 6.2.1
start
scheduled
nextTick callback
setTimeout 0 callback
setTimeout 1 callback
setImmediate callback
setTimeout 0 after setImmediate callback
setTimeout 1 after setImmediate callback
$ node test.js
nodejs version 6.2.1
start
scheduled
nextTick callback
setTimeout 0 callback
setTimeout 1 callback
setTimeout 0 after setImmediate callback
setTimeout 1 after setImmediate callback
setImmediate callback
Expected output:
$ node test.js
nodejs version 6.2.1
start
scheduled
nextTick callback
setImmediate callback
setTimeout 0 callback
setTimeout 1 callback
setTimeout 0 after setImmediate callback
setTimeout 1 after setImmediate callback
Activity
mscdex commentedon Jun 4, 2016
/cc @Fishrock123
bnoordhuis commentedon Jun 5, 2016
I think this is a documentation issue. The documentation is correct about the order of events except at start-up, before node enters the event loop. If you wrap the test case in a setTimeout(), the order of events is as you would expect.
Worthwhile to point out: setTimeout(0) and setTimeout(1) are really the same thing, they both start a timer with a 1 millisecond timeout.
tristanls commentedon Jun 5, 2016
Thank you for the explanation. I confirmed that wrapping in
setTimeout(...)results in expected order.cjihrig commentedon Jun 5, 2016
@tristanls would you like to take a crack at improving the docs?
tristanls commentedon Jun 5, 2016
@cjihrig I plan on doing so.
blacksun1 commentedon Jan 17, 2017
CC: @cjihrig, @tristanls
Hey guys,
I got tripped up on this issue today as well. I see that this documentation update wan't committed and looks like it has been forgotten about or just no one has had time to put it in.
Would you like me to have a crack at redoing this now that #6937 is in place?
Regards,
blacksun1 commentedon Jan 17, 2017
Wow, OK, I think that this is just broken as per the following
Basically, just run this code and my expectation is that it should just keep on running. In fact, what happens is after a random number of iterations it will stop with an error such as
I think that this is probably caused by issue Make setTimeout and setImmediate timers run consecutively #8460.
jasnell commentedon Jan 17, 2017
@Fishrock123
Fishrock123 commentedon Jan 17, 2017
@bnoordhuis That sounds like a bug to me. Is that because we execute startup in
nextTick?#8460 sounds like it may be potentially the actual problem, I probably did not recognize it because there was no testcase.
Trott commentedon Jul 15, 2017
@Fishrock123 Same questions here as in #8460 (comment)
mannanali413 commentedon Dec 27, 2017
@Fishrock123 and @Trott does this bug still exist? I can work on this :)
Trott commentedon Dec 27, 2017
Seems like it to me.
PranayPant commentedon Jan 21, 2018
Is this really an issue? nodejs/help#392 explains how that's intended functionality if im not mistaken
apapirovski commentedon Apr 12, 2018
The issue reported above by @blacksun1 was fixed in a semver-major commit and will land in 10.x. Unfortunately I don't think it can be back-ported.