As explained at the beginning of this chapter, Node's concurrency model is single-threaded
and event-based. But in version 10 and later, Node does allow true multithreaded
programming, with an API that closely mirrors the Web Workers API defined by web browsers
(15.13). Multithreaded programming has a well-deserved reputation for being difficult.
This is almost entirely because of the need to carefully synchronize access by threads to
shared memory. But JavaScript threads (in both Node and browsers) do not share memory by
default, so the dangers and difficulties of using threads do not apply to these "workers"
in JavaScript.
Instead of using shared memory, JavaScript's worker threads communicate by message
passing. The main thread can send a message to a worker thread by calling the
postMessage() method of the Worker object that represents that thread. The worker thread
can receive messages from its parent by listening for "message" events. And workers can
send messages to the main thread with their own version of postMessage(), which the
parent can receive with its own "message" event handler. The example code will make it
clear how this works.
There are three reasons why you might want to use worker threads in a Node
application:
If your application actually needs to do more computation than one CPU core can handle,
then threads allow you to distribute work across the multiple cores, which have become
commonplace on computers today. If you're doing scientific computing or machine learning
or graphics processing in Node, then you may want to use threads simply to throw more
computing power at your problem.
Even if your application is not using the full power of one CPU, you may still want to use
threads to maintain the responsiveness of the main thread. Consider a server that handles
large but relatively infrequent requests. Suppose it gets only one request a second, but
needs to spend about half a second of (blocking CPU-bound) computation to process each
request. On average, it will be idle 50% of the time. But when two requests arrive within
a few milliseconds of each other, the server will not even be able to begin a response to
the second request until the computation of the first response is complete. Instead, if
the server uses a worker thread to perform the computation, the server can begin the
response to both requests immediately and provide a better experience for the server's
clients. Assuming the server has more than one CPU core, it can also compute the body of
both responses in parallel, but even if there is only a single core, using workers still
improves the responsiveness.
In general, workers allow us to turn blocking synchronous operations into nonblocking
asynchronous operations. If you are writing a program that depends on legacy code that is
unavoidably synchronous, you may be able to use workers to avoid blocking when you need
to call that legacy code.
Worker threads are not nearly as heavyweight as child processes, but they are not
lightweight. It does not generally make sense to create a worker unless you have
significant work for it to do. And, generally speaking, if your program is not CPU-bound
and is not having responsiveness problems, then you probably do not need worker
threads.