Many developers wonder at some point in their Node.js programming journey that, is Node.js really single-threaded? If it is, how is it able to do asynchronous execution? Some people understand it in terms of even loop, but there is more to it. I hope you understand what event loop is since you are reading this. But, if you don’t, check out this awesome talk by Philip Roberts.
In Chrome, Javascript runs in a single thread. You are sharing the same thread for rendering as well as your code execution. Chrome actually employs multi-process architecture, which means that each tab, plugin in your browser is getting a new process. And any crash or block is not effecting others. When JS code is executed in the browser, it is essentially blocking the browser painting or render since there is no thread to do the same. But before it picks something from the callback queue after the current call stack is empty, browser paint actually takes precedence. That’s about the browser. But, how do things go in a backend JS runtime, Node.js?
The answer to the above question, Node.js is single-threaded similar to Javascript. So, your JS code is running in a single thread(main thread) in consensus with the event loop and callback queue. But, Node.js is not purely Javascript code. Some of it is C++ code, some things when done asynchronously like network calls, file system tasks, DNS lookup, etc. are actually not handled by the main thread. Node.js does this optimization of using C++ code(which has access to multiple threads) internally for these tasks, which helps in reducing the execution time when used correctly. Node.js actually does offload the asynchronous tasks to C++ code, where it has the provision to use multiple threads to speed up execution, but if you force it to be sync(using only the synchronous version of the API), you are binding it not to do this optimization.
Top comments (12)
I will do a joke. It will be very bad.
So Node.js is married-threaded.
It's been 6 hours. How to get this out of my head? It's very bad. 😣
Very bad indeed
I concur
So does this mean that there's no advantage in running Node on a super beefy 16 core machine?
Honestly, if you're looking to make use of heavy multithreading; Javascript just isn't the language you should be looking at I'm fraid
It's a practice to spawn multiple instances of the app with this type of setup.
Have a look at cluster module.
nodejs.org/api/cluster.html
To get started with multiple instances, have a look at pm2. You can spawn as many instances as your cpu cores.
pm2.keymetrics.io/
More an aside, but this was a great Node.js course on Frontend Masters that I did once. It touches on the usage of
libuvunder the hood for anyone who finds this discussion topic fascinating frontendmasters.com/courses/server...From what I can tell (correct me if I'm wrong), this uses service workers under the hood.
Those have the problem that you're not able to share memory, so if you want to pass large amounts of data around, you're effectively copying it every time it moves between threads.
While perhaps not problematic for some, I see this cause problems on large scale if you're not careful about what you're passing around; as well as the issue that suddenly you're not passing by reference whereas a regular function call would (for objects etc).
Asynchronous execution does not mean parallel execution. Node runs asynchronous tasks concurrently.
True to some extent(per each worker). But, offloading multiple tasks to libuv thread pool essentially make it parallel.