CODEWITHSUNDEEP
node.js
Zenul_Abidin
Zenul_Abidin

Reputation: 809

Does node.js limit the number of concurrent callbacks?

I'm new to Node.js and have been studying callbacks and promises lately. So let's say that I have this chain of promises (an example I took from here):

fs.readFile('test.txt')
  .then(function (data) {
    return db.insert({
      fileName: 'test.txt',
      fileContent: data
    });
  })
  .then(function (document) {
    return smtp.send({
      to: '[email protected]',
      subject: 'test',
      body: 'This is a notification email about' + document.fileName + '.'
    });
  })
  .then(function () {
    console.log("Success email sent.");
  }, function (err) {
    console.error(err);
  });

// More code here...

All of this is going to run in one thread. But if after More code here I call another function with a callback/promise, to my understanding, that will run on a second thread.

A normal system only has a few threads, like 2, 4 or 8. If I put several functions with callbacks one after the other, theoretically Node will use that many threads. But does Node limit the number of threads that it uses to the amount the machine has, so it doesn't hang the OS? Should I be concerned if I have several functions/callbacks after each other like this in my file?

Upvotes: 0

Views: 504

Answers (1)

CherryDT
CherryDT

Reputation: 29012

No, node.js is single-threaded (unless you use worker-threads, but that's a different story entirely). To achieve what looks like concurrency, node.js uses an event loop. Basically, when something is waiting, it returns to the event loop, and the event loop will see what other things there are to do (process events). One of the other things to do may be continuing execution of another piece of code that was previously waiting.

You can imagine it like cooking a complicated meal where you do many things in parallel. That's actually pretty much an event loop. You are giving something attention, and when you are done giving it immediate attention, you are checking what happened in the meantime and if there is anything else to react on, if yes you do that, and so on, until eventually everything is done. You have several things on your stove cooking in parallel and when one of it needs attention, you give it, yet you still operate only with one cook (thread). (By the way this also shows why you shouldn't block an event loop by having something that runs synchronously for a very long time - imagine getting a phone call in the middle of cooking and getting distracted for 5 minutes, i.e. not processing events... only to find everything burning afterwards)

Since threads aren't involved there at all, there is also no limitation as to how many things are waiting. (The only limitation is your RAM.)

Also, a note on what you wrote about systems having limited threads: That's not true in the way you wrote it, it seems you are confusing hardware threads with software threads. What you were probably referring to were processor threads which are hardware-supported virtual CPU cores. This is several layers of abstraction below the code you write. Software threads are a different concept, managed by the operating system. A process can have many more threads than there exist in hardware, but their real concurrency will be limited. So for example if you have 100 threads and your processor provides 4, then no more than 4 can ever run in parallel (and often less since there will be other things happening in your system). The times at which they get to run is managed by the operating system's scheduler, ensuring that each (software) thread gets a "fair share" of the available processor power, switching every few microseconds, so it feels as if all 100 were running in parallel.

Upvotes: 1

Related Questions