1

let's say we have a very CPU intensive code in NodeJs:

for (var i = 0; i < 1e10; i++){}

I've heard that under the hood nodejs uses pool threads for handling asynchronous code. So my question is: Is there any difference between converting this job to a promise such as:

const p = new Promise((resolve, reject) => {
    for (var i = 0; i < 1e9; i++){
        if (i == 1000) resolve("ok");
    }
}).then(result => { 
    console.log('res ' + result)
})

and creating a new worker thread for handling this CPU intensive work, once nodejs already do that under the hood? Also if they are both the same under the hood why would people argue that using workers for handling cpu intensive is better if none of the ways blocks the event loop?

Question about nodeJs event loop, async vs multithreading in Nodejs.

  • A [worker thread or web worker](https://stackoverflow.com/a/30891727/1318694) which provides another JS event loop is different to a Promise, which remains on the JS thread it was created on. – Matt Feb 06 '23 at 22:54
  • A promise is sometimes used to wrap some native code, like nodes `fs`, `http`, `crypto` or `dns`, that native code may run on the [libuv threadpool](https://stackoverflow.com/questions/22644328/when-is-the-thread-pool-used/22644735#22644735). – Matt Feb 06 '23 at 22:56

1 Answers1

0

There is no difference. The Promise executor function is called synchronously. So, both cases are just running your for loop synchronously.

Although the second (Promise) version calls resolve() after only 1000 iterations of the loop, it still won't be able to call the .then() handler until after the entire for loop finishes because that's how promises are designed to work. They wait for control to return back to the event loop before they can call .then() or .catch() handlers.

No thread pools are involved in any of the code you show. That's just the main thread running your Javascript.

Promises are JUST a notification system. They don't make something that runs synchronously magically run asynchronously. They can sometimes be used to shift WHEN something runs (to run it later), but when it runs, it still runs the same as it did if it wasn't wrapped in a promise.

To make something actually run asynchronously (so that it doesn't block the main thread), you would have to either rewrite it using actual asynchronous operations or you'd have to put the synchronous code in a workerThread to stop it from blocking the main thread.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • 1
    In my mind I could transform anything into a promise and nodeJs would keep the event loop and come back when it finished it, so I haven't seen any difference between promises and a multithread, but as soon as I've read your answer I realized the difference, and indeed even if a piece of code is inside a promise doesn't mean it is non-blocking, I tested and you are right, now I truly understand why I should delegate some tasks to another thread. – Guilherme Gavioli Feb 07 '23 at 04:13