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?
2
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.
http://ejohn.org/blog/how-javascript-timers-work/
1
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.