Grasping the Node JS alternative to multithreading


If I understand correctly Node JS is non blocking…so instead of waiting for a response from a database or other process it moved on to something else and checks back later.

Also it is single threaded.

So does all this mean that a given Node JS process can fully and efficiently utilize a single CPU core but it will not use any other core on the machine, as in, it will never use more than one at a time.

This of course means that the other CPUs can still be used by other processes for things like SQL database or other intentionally separated CPU heavy subroutines as long as they are a separate process.

Also in the event that the Node JS process has an endless loop or long running function, that process is no longer useful in any way until the endless loop or long running function is stopped (or whole process killed).

Is all this right? Am I correct in my understanding?

Problem courtesy of: George Bailey


Pretty much correct, yes. The node.js server has an internal thread pool so it can perform blocking operations and notify the main thread with a callback or event when things complete.

So I imagine that it will make limited use of another core for the thread pool, for example if you do a non-blocking file system read this is likely implemented by telling a thread from the thread pool to perform a read and set a callback when it’s done which means that the read could be happening on a different thread/core while the main node.js program is doing something else.

But from a node.js point of view, it’s entirely single threaded and won’t directly use more than one core.

Solution courtesy of: jcoder

View additional discussion.