Execution order: setImmediate, setTimeout, fs.stat, fs.readFile

[ulugbekov]

Hi,
Execution order is different.
setImmediate is executing before fs.readFile and after fs.stat.
setImmediate is executing after setTimeout for time = 0.

Per Documentation:
setImmediate should execute after I/O operation callbacks.
setImmediate should execute before setTimeout.

Thanks

[indutny]

I don't think that your report fully holds. Try this: https://gist.github.com/indutny/3ffc37502cf07b1b2c4b

I get:

~/Code/indutny/node $ ./node 2
immediate 1
immediate 2
timeout

[indutny]

Regarding I/O, it doesn't mean that calling fs.readFile() and setImmediate() will result in readFile()'s callback invoked first. It just means that if there are queued callbacks to be executed on a next loop's tick, the setImmediate() will be executed after them.

[ulugbekov]

Thanks for comments.
Tried your code on my machine.

timeout
immediate 1
immediate 2

Can't believe why this is happening.

[indutny]

What node.js version are we talking about, and what OS are you running it on?

[cjihrig]

@indutny I'm seeing non-deterministic different orders. I've tested 0.11.13 and 0.10.28 on OS X. From what I've seen, immediate1 always comes before immediate 2, but there is no relation between the immediates and timeout. However, this behavior seems to be in line with this comment - #6034 (comment)

[vkurchatkin]

@cjihrig indeed. Looks like something in setTimeout implementation introduces nondeterminism. The following works as expected:

var Timer = process.binding('timer_wrap').Timer;

setImmediate(function() {
  console.log('immediate 1');
});

var t = new Timer();
t[Timer.kOnTimeout] = function () {
  console.log('timeout');
}
t.start(0, 0);

setImmediate(function() {
  console.log('immediate 2');
});

timeout
immediate 1
immediate 2

[trevnorris]

I'm just crap shooting this, but it might have to do with the fact that on
the initial run of setTimeout() the TimerWrap class needs to be
instantiated. It might be that the queue is immediately processed because
of this.

While this is slightly perplexing, I don't believe Node has ever made the
guarantee that one will always run before the other. In fact, I have an old
PR that needs to be tidied up that makes it so the close callbacks won't
run until the uv__run_closing_handles() phase of the event loop. Which
would always cause setImmediate() and setTimeout() to run in reverse order.

Guess what I'm getting at is, is this really an issue or just an oddity of
implementation details?

[ulugbekov]

Mac OSX 10.6.8,
Node 0.10.26 and 0.10.28