Does Settimeout run in parallel on Node.js?

Asked

Viewed 57 times

2

I’m studying the concepts of asymchronism, I know that Node.js is single-threaded and that for some types of task he delegates the same to the libuv (which has 4 threads by default) and others for the manager itself threads operating system. However, when testing a code snippet using multiple calls from setTimeout the console.time() returns 1 second for all of them. The setTimeout runs in parallel?

What I understood about the Event loop is that it goes "stacking" asynchronous tasks and performs them in sequence, but I don’t understand why several setTimeoutscheduled to run after 1 second are returned at the same time.

Code snippet:

function sum(a, b) {
    return new Promise(function (resolve) {
        setTimeout(function () {
            resolve(a + b)
        }, 1000)
    })
}

console.time('start')
Promise.all([
    sum(1, 2),
    sum(3, 5),
    sum(3, 5),
    sum(3, 5),
    sum(3, 5),
    sum(3, 5),
    sum(3, 5),
]).then(res => {
    console.timeEnd("start")
})

Exit:

start: 1004.434ms

1 answer

3


Settimeout runs in parallel in Nodejs?

No. In Javascript there is no parallelism. At least not until the introduction of Worker threads in Node.js or the Webworkers in the browser. There you can consider parallelism, but in "pure" Javascript, as in the question code, no.

What you’re making it look like is parallel is a ruse of Promise.all, that awaits the resolution of all the promises to resolve.

That way, when you create the array literal:

[
    sum(1, 2),
    sum(3, 5),
    sum(3, 5),
    sum(3, 5),
    sum(3, 5),
    sum(3, 5),
    sum(3, 5),
]

You are calling the function sum 6 times, so that one will be called soon after the other. Something like this:

  • Call sum with 1 and 2;
  • Call sum with 3 and 5;
  • ...

In this way, you can see that they are not being invoked in parallel, but rather sequentially. Note, however, that they all return one Promise. Since all the functions were carried out almost at the same time, all the promises will be resolved a second later, which will solve Promise.all, almost 1 second after the start of the script.

The 4.434ms the remainder are, in part, due to the execution of the functions synchronously, so that the latter is invoked some fractions of a second after the first. It is almost instantaneous. In addition, there is also the process of resolving promises. The "message" of resolution of promises is passed sequentially to Promise.all, which adds a few more fractions of a second.

The event loop schedules, processes and returns only one item at a time (the order of these actions may vary, as in the question code) and setTimeout, others timers, promises or Promise.all are no exceptions to that rule.

To learn more about this "near parallelism" of Promise.all (and other aggregators of Promise similar), see this other question.

  • Got it, so ,roughly speaking, one can say all are scheduled on the Vent-loop almost at the same time and also end almost at the same time, the "broken numbers" is the time that the Vent loop sends the "messages", right? I think I confused the scheduling in Event-loop with the running time, from the time that is sent to Event-loop already starts counting, right?

  • That’s basically it. I just don’t understand what "count" you mean. If it’s the time of setTimeout, yes.

  • 1

    That would be the setTimeout countdown. Thanks!

Browser other questions tagged

You are not signed in. Login or sign up in order to post.