Worker thread vs child process in Node.js

Introduction

Worker threads and child processes help Node.js run tasks at the same time without waiting. They make your app faster by doing work in the background.

When you want to run heavy calculations without freezing the main app.

When you need to run separate programs or scripts alongside your main app.

When you want to use multiple CPU cores to speed up tasks.

When you want to keep your app responsive while doing long tasks.

When you want to isolate tasks so errors don't crash the main app.

Syntax

Node.js

const { Worker } = require('worker_threads');

const worker = new Worker('./worker.js');

worker.on('message', (msg) => {
  console.log('From worker:', msg);
});

worker.postMessage('start');

// For child process
const { fork } = require('child_process');

const child = fork('./child.js');

child.on('message', (msg) => {
  console.log('From child:', msg);
});

child.send('start');

Worker threads share memory with the main thread but run code in parallel.

Child processes run completely separate programs and communicate via messages.

Examples

This example creates a worker thread that replies with a greeting message.

Node.js

const { Worker } = require('worker_threads');

const worker = new Worker(`
  const { parentPort } = require('worker_threads');
  parentPort.on('message', (msg) => {
    parentPort.postMessage(`Hello, ${msg}`);
  });
`, { eval: true });

worker.on('message', (msg) => console.log(msg));
worker.postMessage('World');

This example forks a child process that replies with 'pong' when it receives 'ping'.

Node.js

const { fork } = require('child_process');

const child = fork('child.js');

child.on('message', (msg) => console.log(msg));
child.send('ping');

// child.js
process.on('message', (msg) => {
  process.send(`pong to ${msg}`);
});

Sample Program

This program shows both a worker thread and a child process doing a heavy calculation separately. Both send results back to the main app.

Node.js

const { Worker } = require('worker_threads');
const { fork } = require('child_process');

// Worker thread example
const worker = new Worker(`
  const { parentPort } = require('worker_threads');
  parentPort.on('message', (msg) => {
    // Simulate heavy work
    let count = 0;
    for(let i=0; i<1e7; i++) count += i;
    parentPort.postMessage(`Worker done: ${count}`);
  });
`, { eval: true });

worker.on('message', (msg) => {
  console.log(msg);
});
worker.postMessage('start');

// Child process example
const child = fork('./child.js');

child.on('message', (msg) => {
  console.log(msg);
});
child.send('start');

// child.js content:
// process.on('message', (msg) => {
//   // Simulate separate task
//   let sum = 0;
//   for(let i=0; i<1e7; i++) sum += i;
//   process.send(`Child done: ${sum}`);
// });

Important Notes

Worker threads are better for CPU-heavy tasks inside the same app.

Child processes are good for running separate programs or scripts.

Communication between them uses messages, so data is copied, not shared (except worker threads can share memory with special objects).

Summary

Worker threads run code in parallel inside the same app and share memory.

Child processes run separate programs and communicate by sending messages.

Use them to keep your app fast and responsive during heavy or separate tasks.

Practice

1. Which statement best describes the difference between worker threads and child processes in Node.js?

easy

A. Worker threads run in the same process sharing memory, while child processes run in separate processes with separate memory.

B. Worker threads run separate programs, child processes share the same memory space.

C. Both worker threads and child processes run in the same process and share memory.

D. Child processes run inside worker threads to improve performance.

Solution

1. Step 1: Understand worker threads behavior

   Worker threads run JavaScript code in parallel but inside the same Node.js process and share memory.

2. Step 2: Understand child processes behavior

   Child processes run completely separate programs with their own memory space and communicate via messages.

3. Final Answer:

   Worker threads run in the same process sharing memory, while child processes run in separate processes with separate memory. -> Option A

4. Quick Check:

   Worker threads share memory, child processes do not [OK]

Hint: Remember: threads share memory, processes do not [OK]

Common Mistakes:

• Confusing memory sharing between threads and processes
• Thinking child processes share memory
• Assuming worker threads run separate programs

2. Which of the following is the correct way to create a worker thread in Node.js?

easy

A. const worker = spawn('worker.js');

B. const worker = fork('worker.js');

C. const worker = createThread('worker.js');

D. const worker = new Worker('worker.js');

Solution

1. Step 1: Recall worker thread creation syntax

   Worker threads are created using the Worker class from the worker_threads module.

2. Step 2: Identify correct constructor usage

   The correct syntax is new Worker('filename'). The fork and spawn methods are for child processes.

3. Final Answer:

   const worker = new Worker('worker.js'); -> Option D

4. Quick Check:

   Worker threads use new Worker() [OK]

Hint: Use new Worker() for threads, fork/spawn for processes [OK]

Common Mistakes:

• Using fork() to create worker threads
• Using spawn() for worker threads
• Using non-existent createThread() function

3. Consider this Node.js code snippet using a child process:

const { fork } = require('child_process');
const child = fork('child.js');
child.on('message', msg => console.log('Parent got:', msg));
child.send('Hello');

What will the parent process output if child.js sends back { reply: 'Hi' } on receiving a message?

medium

A. Parent got: Hello

B. Parent got: { reply: 'Hi' }

C. Parent got: Hi

D. No output, error occurs

Solution

1. Step 1: Understand child process communication

   The parent sends 'Hello' to the child. The child responds with an object { reply: 'Hi' } via process.send().

2. Step 2: Analyze parent's message event handler

   The parent's child.on('message') receives the object and logs it as Parent got: { reply: 'Hi' }.

3. Final Answer:

   Parent got: { reply: 'Hi' } -> Option B

4. Quick Check:

   Child sends object, parent logs object [OK]

Hint: Child sends object, parent logs exact message [OK]

Common Mistakes:

• Assuming string 'Hi' instead of object
• Expecting parent's message to be 'Hello'
• Confusing child and parent message directions

4. What is wrong with this code snippet that tries to create a worker thread?

const { Worker } = require('worker_threads');
const worker = Worker('worker.js');

medium

A. The file 'worker.js' must be a JSON file

B. Wrong module imported, should be 'child_process'

C. Missing new keyword before Worker constructor

D. Worker threads cannot be created with a filename

Solution

1. Step 1: Check Worker thread creation syntax

   The Worker class must be instantiated with the new keyword.

2. Step 2: Identify error in code

   The code calls Worker('worker.js') without new, causing a TypeError.

3. Final Answer:

   Missing new keyword before Worker constructor -> Option C

4. Quick Check:

   Use new Worker() to create threads [OK]

Hint: Always use new with Worker() constructor [OK]

Common Mistakes:

• Forgetting new keyword
• Importing wrong module for threads
• Thinking worker.js must be JSON

5. You want to perform a CPU-heavy task in Node.js without blocking the main event loop. Which approach is best and why?

hard

A. Use a child process to run the task in a separate process communicating via messages.

B. Use a worker thread to run the task sharing memory with the main thread.

C. Run the task directly in the main thread asynchronously.

D. Use setTimeout to delay the task execution in the main thread.

Solution

1. Step 1: Understand CPU-heavy task impact

   CPU-heavy tasks block the main event loop if run directly, causing app unresponsiveness.

2. Step 2: Compare worker threads and child processes for heavy tasks

   Worker threads share memory but still run in the same process, which can cause contention. Child processes run in separate processes, isolating CPU load and preventing blocking.

3. Step 3: Evaluate other options

   Running asynchronously in main thread or delaying with setTimeout does not prevent blocking for CPU-heavy tasks.

4. Final Answer:

   Use a child process to run the task in a separate process communicating via messages. -> Option A

5. Quick Check:

   Heavy CPU tasks best isolated in child processes [OK]

Hint: Heavy CPU tasks? Use child processes to avoid blocking [OK]

Common Mistakes:

• Assuming worker threads fully isolate CPU load
• Thinking async or setTimeout avoids CPU blocking
• Ignoring message communication overhead