Javascript internals - clearTimeout just before it fires

Question

Let's say I do this:

var timer = setTimeout(function() {
    console.log("will this happen?");
}, 5000);

And then after just less than 5 seconds, another callback (from a network event in NodeJS for example) fires and clears it:

clearTimeout(timer);

Is there any possibility that the callback from the setTimeout call is already in the queue to be executed at this point, and if so will the clearTimeout be in time to stop it?

To clarify, I am talking about a situation where the setTimeout time actually expires and the interpreter starts the process of executing it, but the other callback is currently running so the message is added to the queue. It seems like one of those race condition type things that would be easy to not account for.

score 7 · Answer 1 · answered Jun 29 '15 at 04:04

Even though Node is single thread, the race condition the question describes is possible.

It can happen because timers are triggered by native code (in lib_uv). On top of that, Node groups timers with the same timeout value. As a result, if you schedule two timers with the same timeout within the same ms, they will be added to the event queue at once.

But rest assured node internally solves that for you. Quoting code from node 0.12.0:

timer.js > clearTimeout

exports.clearTimeout = function(timer) {
  if (timer && (timer[kOnTimeout] || timer._onTimeout)) {
    timer[kOnTimeout] = timer._onTimeout = null;
    // ...
  }
}

On clearing a timeout, Node internally removes the reference to the callback function. So even if the race condition happens, it can do no harm, because those timers will be skipped:

listOnTimeout

if (!first._onTimeout) continue;

score 5 · Accepted Answer · edited May 23 '17 at 12:16

5

Node.js executes in a single thread.

So there cannot be any race conditions and you can reliably cancel the timeout before it triggers.

See also a related discussion (in browsers).

I am talking about a situation where the setTimeout time actually expires and the interpreter starts the process of executing it

Without having looked at Node.js internals, I don't think this is possible. Everything is single-threaded, so the interpreter cannot be "in the process" of doing anything while your code is running.

Your code has to return control before the timeout can be triggered. If you put an infinite loop in your code, the whole system hangs. This is all "cooperative multitasking".

edited May 23 '17 at 12:16

Community

1
1

answered Jun 10 '14 at 09:51

Thilo

257,207
101
511
656

I dont think its appropriate to say `Node.js executes in a single thread. So there cannot be any race conditions`. For a good explanation see this comment https://blog.raananweber.com/2015/06/17/no-there-are-no-race-conditions-in-javascript/#comment-3304001430 Perhaps this descends into a discussion about the definition of a 'race condition' – wal Oct 13 '18 at 14:17

score 0 · Answer 3 · answered May 12 '19 at 02:17

This behavior is defined in the HTML Standard, the fired task starts with:

If the entry for handle in the list of active timers has been cleared, then abort these steps.

Therefore even if the task has been queued already, it'll be aborted.

Whether this applies to Node.js, however, is debatable, as the documentation just states:

The timer functions within Node.js implement a similar API as the timers API provided by Web Browsers but use a different internal implementation that is built around the Node.js Event Loop.

Javascript internals - clearTimeout just before it fires

3 Answers3