Are animated Node.js tasks being processed synchronously?
Consider the following piece of code:
var some_expensive_task = function(i) {
setTimeout(function() {
var a = 1;
while (a < 100000000) {
Math.sqrt(a);
++a;
}
console.log('finished set' + i);
}, 0);
};
for (var i = 0; i < 70; ++i) {
console.log('start ' + i);
some_expensive_task(i);
console.log('end ' + i);
}
The goal of this program was to iterate over and run intensive asynchronous tasks at 70 cpu using setTimeout.
As expected, the output of this program is:
start 1
end 1
...
start 69
end 69
finished set1
...
finished set69
Capturing the entire execution, there were only two processes. One was I guess was an idle cycle and the other was a 100% workflow.
Am I correct in understanding that when the event loop is executed synchronously, asynchronous tasks that run regardless of the source are executed synchronously in the order in which they were called?
UPDATE
I still don't think I have detailed my question in sufficient detail. Using setTimeout was the only way to accurately plan the set of async functions to run. I guess the real question is that if I run three async functions with setTimeout, still with zero latency, this is the second one I run to ensure that it runs after the first one is finished and will is it the third to start after the second is completed?
source to share
You are using the wrong terminology in the question, it Are Node.js asynchronous tasks handled synchronously
doesn't make a lot of sense. And the test case is not what you think. First, we outline some terms:
Synchronous functions are guaranteed to execute / complete in the order they are called.
Asynchronous functions can advance and complete their out-of-order wrto calls.
Blocking operations are those operations that once started, must complete for further execution. CPU intensive operations are blocked unless you run their separate worker. loops block nature. Once they start, they will complete all iterations until the next function is executed.
setTimeout simply calls the passed function at least x ms after the current time. Calling this means that once x ms passes the queue to the passed function in the event loop. It's just a deferred execution.
Therefore, considering the facts above, this is why your test is misleading:
-
First your test case (your CPU intensive) is not asynchronous, you wrapped it around setTimeout which is asynchronous. A timeout of 0 simply means that they will execute in the same order they are called. All callback functions are synchronous.
-
Second, the start and end in the log indicates the point where your setTimeout is called. It will be ok as expected. With a timeout of 0, completion will be fine. Yes, if you have an equal timeout for them, they will all be executed in the same order in which they were sent. Again, this is one of many possible cases where the result is similar to synchronous (what if the timeouts were in ascending order?). What you asked for may be true for these cases, but not always.
-
Third, if you want to simulate asynchrony (enough to see the behavior out of order on the console), you might as well lose your while loop and use random timeouts (
Math.random()*1000
). You will see that they are completed at random. This will be asynchronous execution (from setTimeout not callback).
source to share
Yes. Javascript, including NodeJS, is single threaded (with a few exceptions).
When you use it setTimeout(fn, 0)
, it pauses the execution of the function after the current call's stack has cleared. In your example, this means that the loop for
will end before the "expensive tasks" start.
source to share
Your JS code runs in a single thread in Node.js. All other native Node.js APIs are written in C / C ++ and are either asynchronous or run on a separate thread. See this answer for a more detailed explanation.
Am I correct in understanding that when the event loop is executed synchronously, asynchronous tasks that run regardless of the source are executed synchronously in the order in which they were called?
Yes you are right.
source to share