Child Processes & Worker Threads
The problem
Node's single-threaded event loop is excellent for I/O-bound work but has no good answer for CPU-bound work — a heavy computation (image processing, complex parsing) run directly on the main thread blocks the event loop entirely, freezing every other request the server is handling.
Why now
Processes and threads already established the OS-level distinction between full process isolation and lighter-weight shared-memory threads; Node exposes both explicitly, because the event loop's single-threaded model means CPU-bound work has to be deliberately moved off it using one of these two OS primitives, not hidden away automatically.
Mental model
A child process is a fully separate Node instance — its own memory, its own event loop, communicating with the parent only via message passing (the interprocess communication already covered). A worker thread is lighter: it shares the process but gets its own JavaScript engine instance and event loop, communicating via message passing too, since JavaScript's memory model doesn't allow arbitrary shared mutable objects between threads the way some other languages do.
Requires
- Processes & ThreadsOperating Systems
Child processes and worker threads are Node's direct, explicit exposure of exactly the OS-level process/thread distinction already covered; you need that distinction (isolation vs. shared memory) before choosing between Node's two concrete APIs for it is meaningful.
- Interprocess CommunicationOperating Systems
Both child processes and worker threads communicate with their parent exclusively through message passing, not shared mutable state; you need the IPC message-passing model already covered to understand why Node's API looks the way it does.
Unlocks
Used in
- Offloading CPU-intensive work (image resizing, complex calculations) off the main event loop
- Running shell commands or other programs from within a Node application via child_process
- Parallelizing independent CPU-bound tasks across multiple worker threads
- Understanding why Node.js isn't 'single-threaded' in the way that phrase often gets oversimplified to mean
Projects
- Run a CPU-intensive synchronous computation directly on the main thread and observe the server become unresponsive to other requests, then move it to a worker thread and confirm responsiveness is restored
- Use child_process to run an external command and correctly handle its stdout, stderr, and exit code
Examples
- A synchronous, CPU-heavy JSON.parse of a huge file blocks every other request on the server until it finishes — moving that parse to a worker thread frees the main thread to keep serving requests
- child_process.exec('ls -la') runs a shell command and returns its output asynchronously via a callback, without blocking the event loop while the external process runs
Resources
Mastery checklist
- I can explain why CPU-bound work blocks Node's single event loop
- I can move a CPU-intensive task to a worker thread and communicate results back via messages
- I can use child_process to run an external command and handle its output correctly
- I can explain the difference between a child process and a worker thread