Consider following JavaScript code:

function foo(ary) {
  // some long operation on ary
function bar(ary) {
  // some long operation on ary
function baz(ary) {
  // some long operation on ary

function main(ary) {
  setTimeout(foo, 0, ary);
  setTimeout(bar, 0, ary);
  setTimeout(baz, 0, ary);

main([some large array]);

From MDN setTimeout():

Code executed by setTimeout() is run in a separate execution context to the function from which it was called.

But does this mean it executes in parallel to any other code that is currently in process?

Considering the example I posted above, assuming a very large array being processed by 3 function, each doing a very long operation on it but are independent of each other, will the 3 functions execute in parallel?

Is there any way on showing the execution of (multiple) setTimeouts, maybe using Chrome Dev Tools?

  • 1
    The answers below are correct that this code has absolutely no parallelism going on, but it's worth mentioning that the Web Workers API is the main way you would go about creating genuine background threads in client-side code.
    – Ixrec
    Commented Apr 5, 2016 at 8:42
  • 2
    Incidentally, the very next sentence on the MDN page you quoted is "As a consequence, the this keyword for the called function will be set to the window (or global) object; it will not be the same as the this value for the function that called setTimeout." which makes it fairly clear that their use of "execution context" was referring to things like the this value rather than threads.
    – Ixrec
    Commented Apr 5, 2016 at 8:47

3 Answers 3


No, it doesn't. "Execution context" doesn't mean "thread", and until recently Javascript had no support for anything resembling threads. What actually happens is that an event is pushed onto the event queue that's set to execute in the number of milliseconds specified by the second argument to SetTimeout/SetInterval. The consequence of this is that if you request a 1000ms delay, then 1000ms is the MINIMUM delay you'll get. If the execution engine is busy doing something else when the 1000ms delay is over then it will have to wait until it's done with what it's doing.

"Execution context" refers to what variable scoping rules are going to apply to the setTimeout callback, meaning that the this variable might not be pointing at what you think it will be, etc.


  • Thank you. Although all 3 answers are good, and I could only accept 1, I am accepting this answer since the link you posted helped me understand more about timers in JS. Commented May 8, 2016 at 21:23

But does this mean it executes in parallel to any other code that is currently in process?

No, it does not mean that. It will just execute later, when the given time has passed.

Javascript fundamentally does not support multithreading because there are no language facilities to prevent data corruption from simultaneous access nor for having isolated threads communicate via messaging.

A Javascript engine simply processes a queue of events sequentially on a single thread. When the event queue is empty, that thread idles. In a browser, events are added to the queue by user input, page loading, etc. In node.js events can also be HTTP requests or hardware events. And setTimeout() simply adds another kind of event with the additional condition that it should only be added to the queue after a certain time has passed.

The "separate execution context" mentioned in the documentation just means that the this reference will be different than in the function where setTimeout() is called.


By "separate execution context" the doc means in particular that this will be different in all likelihood.

In the browser, JavaScript code of one page is always executed in a single thread. Only JavaScript that is run in a separate worker or page can run in parallel.

One reason for this is that JavaScript has direct access to the DOM and getting that to be thread safe would come at significant performance cost. The reasoning is quite similar for nodejs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.