setTimeout behaviour with blocking code

Question

This is my test code (fiddle here):

console.log('Before wait');
setTimeout(function () { console.log('Yo!'); }, 1000);
var start = Date.now();
while (Date.now() < start + 3000) {}
console.log('After wait');

This is the timeline of events in Chrome:

• Time 0 seconds: Prints "Before wait"
• Time 3 seconds: Prints "After wait", and then immediately after "Yo!"

Is this behaviour according to spec? Why is it not

• Time 0 seconds: Prints "Before wait"
• Time 3 seconds: Prints "After wait"
• Time 4 seoncds: Prints "Yo!"

?

Answer 1

JavaScript is single-threaded. If some block of code uses execution thread, no other code can be executed. This means your setTimeout() call must wait until main execution (the one with busy-waiting while loop) finishes.

Here is what happens: you schedule setTimeout() to execute after a second and then block main thread for 3 seconds. This means the moment your busy loop finishes, timeout is already 2 seconds too late - and JS engine tries to keep up by calling your timeout as soon as possible - that is, immediately.

In fact this:

while (Date.now() < start + 3000) {}

is one of the worst things to do in JavaScript. You hold JavaScript execution thread for 3 seconds and no other event/callback can be executed. Typically browsers "freeze" in that period of time.

Answer 2

The delay of setTimeout is relative to the exact point in time when it is called. It expires while you are still busy waiting. So it will be performed at the next instant where the control goes back into the event loop.

Edit:

The spec is a bit vague in this point, but I guess it's the intended and only straightforward interpretation:

setTimeout(function, milliseconds)

This method calls the function once after a specified number of milliseconds elapses, until canceled by a call to clearTimeout. The methods returns a timerID which may be used in a subsequent call to clearTimeout to cancel the interval.