Bird
Raised Fist0
Node.jsframework~8 mins

Child process exit codes in Node.js - Performance & Optimization

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Performance: Child process exit codes
MEDIUM IMPACT
This concept affects how efficiently a Node.js application handles subprocess termination, impacting responsiveness and resource cleanup.
Handling child process termination to avoid resource leaks and unresponsive behavior
Node.js
const { spawn } = require('child_process');
const child = spawn('someCommand');
child.on('exit', (code, signal) => {
  if (code !== 0) {
    console.error(`Process exited with code ${code}`);
  }
  // Cleanup resources here
});
Listening to exit events ensures timely cleanup and proper handling of exit codes, preventing resource leaks and improving responsiveness.
📈 Performance GainPrevents memory leaks and reduces input lag by freeing resources immediately after process ends.
Handling child process termination to avoid resource leaks and unresponsive behavior
Node.js
const { spawn } = require('child_process');
const child = spawn('someCommand');
// No listener for 'exit' or 'close' events
// No handling of exit codes
Not listening to child process exit events causes missed cleanup opportunities and can lead to zombie processes or hanging resources.
📉 Performance CostCan cause increased memory usage and delayed responsiveness due to unreleased resources.
Performance Comparison
PatternDOM OperationsReflowsPaint CostVerdict
Ignoring child process exit codesN/AN/AN/A[X] Bad
Listening and handling exit codes properlyN/AN/AN/A[OK] Good
Rendering Pipeline
Child process exit codes do not directly affect browser rendering but impact Node.js event loop responsiveness and resource management.
Event Loop
Resource Cleanup
⚠️ BottleneckUnmanaged child processes causing event loop delays and memory bloat
Core Web Vital Affected
INP
This concept affects how efficiently a Node.js application handles subprocess termination, impacting responsiveness and resource cleanup.
Optimization Tips
1Always listen to child process 'exit' or 'close' events to handle termination.
2Check exit codes to detect errors and perform cleanup.
3Avoid ignoring child process termination to prevent memory leaks and event loop blocking.
Performance Quiz - 3 Questions
Test your performance knowledge
Why is it important to listen for child process exit codes in Node.js?
ATo clean up resources and avoid memory leaks
BTo increase the size of the application bundle
CTo block the main thread until the process exits
DTo delay rendering in the browser
DevTools: Node.js Inspector (via Chrome DevTools)
How to check: Run your Node.js app with --inspect flag, open DevTools, go to the Console and Debugger panels, and monitor event loop responsiveness and memory usage while spawning child processes.
What to look for: Look for event loop delays, unhandled promise rejections, and memory leaks indicating poor child process management.

Practice

(1/5)
1. What does an exit code of 0 from a Node.js child process usually mean?
easy
A. The process finished successfully without errors.
B. The process was terminated by a signal.
C. The process encountered an error and crashed.
D. The process is still running.

Solution

  1. Step 1: Understand exit codes in Node.js child processes

    Exit codes indicate how a process ended. Code 0 means success.
  2. Step 2: Interpret exit code 0

    Exit code 0 means the process finished without errors or interruptions.
  3. Final Answer:

    The process finished successfully without errors. -> Option A
  4. Quick Check:

    Exit code 0 = success [OK]
Hint: Exit code 0 always means success in child processes [OK]
Common Mistakes:
  • Confusing exit code 0 with error codes
  • Thinking signal termination returns 0
  • Assuming non-zero codes mean success
2. Which of the following is the correct way to listen for a child process exit event in Node.js?
easy
A. child.listen('exit', (code) => { /* handle exit */ });
B. child.exit(() => { /* handle exit */ });
C. child.onExit((code) => { /* handle exit */ });
D. child.on('exit', (code, signal) => { /* handle exit */ });

Solution

  1. Step 1: Recall Node.js child process event syntax

    Node.js child processes emit events listened with on method.
  2. Step 2: Confirm correct event and parameters

    The 'exit' event uses child.on('exit', (code, signal) => {}) syntax.
  3. Final Answer:

    child.on('exit', (code, signal) => { /* handle exit */ }); -> Option D
  4. Quick Check:

    Use child.on('exit', callback) [OK]
Hint: Use child.on('exit', callback) to catch exit events [OK]
Common Mistakes:
  • Using non-existent methods like exit() or onExit()
  • Using listen() instead of on()
  • Missing parameters in the callback
3. Consider this code snippet:
const { spawn } = require('child_process');
const child = spawn('node', ['-e', "process.exit(5)"]);
child.on('exit', (code, signal) => {
  console.log(`Exit code: ${code}, Signal: ${signal}`);
});

What will be printed when this code runs?
medium
A. Exit code: 0, Signal: null
B. Exit code: 5, Signal: null
C. Exit code: null, Signal: SIGTERM
D. Exit code: 1, Signal: null

Solution

  1. Step 1: Understand the child process exit code

    The child process runs process.exit(5), so it exits with code 5.
  2. Step 2: Check the exit event parameters

    The exit event callback receives code 5 and signal null because it exited normally with code 5.
  3. Final Answer:

    Exit code: 5, Signal: null -> Option B
  4. Quick Check:

    process.exit(5) sets exit code 5 [OK]
Hint: process.exit(n) sets exit code n, signal is null if normal exit [OK]
Common Mistakes:
  • Assuming exit code is always 0
  • Confusing signal with exit code
  • Expecting signal to be set on normal exit
4. You wrote this code to spawn a child process and listen for exit:
const { spawn } = require('child_process');
const child = spawn('node', ['-e', "setTimeout(() => process.exit(0), 1000)"]);
child.unref();
child.on('exit', (code) => {
  console.log(`Exited with code ${code}`);
});

But the console never logs anything. What is the likely problem?
medium
A. The exit event callback is missing the signal parameter.
B. The child process is not exiting because the event loop is blocked.
C. The child process exits after 1 second, but the main program ends before that.
D. The spawn command syntax is incorrect.

Solution

  1. Step 1: Analyze the child process behavior

    The child process exits after 1 second due to setTimeout.
  2. Step 2: Consider the main program lifecycle

    If the main program ends before 1 second, it may exit before child finishes, so no log appears.
  3. Final Answer:

    The child process exits after 1 second, but the main program ends before that. -> Option C
  4. Quick Check:

    Main program must stay alive to see child exit [OK]
Hint: Keep main program alive to catch delayed child exit events [OK]
Common Mistakes:
  • Thinking missing signal parameter breaks event
  • Assuming spawn syntax is wrong without error
  • Ignoring asynchronous timing of child exit
5. You want to run a child process and handle both normal exit and signal termination. Which code snippet correctly logs the exit code or signal received?
hard
A. child.on('exit', (code, signal) => { if (code !== null) console.log(`Exited with code ${code}`); else console.log(`Terminated by signal ${signal}`); });
B. child.on('exit', (code) => { if (code === 0) console.log('Success'); else console.log('Error'); });
C. child.on('close', (signal) => { console.log(`Closed with signal ${signal}`); });
D. child.on('exit', () => { console.log('Process ended'); });

Solution

  1. Step 1: Understand exit event parameters

    The 'exit' event provides two parameters: code (number or null) and signal (string or null).
  2. Step 2: Handle both exit code and signal

    If code is not null, process ended normally; if null, it was terminated by a signal.
  3. Step 3: Check code snippet correctness

    child.on('exit', (code, signal) => { if (code !== null) console.log(`Exited with code ${code}`); else console.log(`Terminated by signal ${signal}`); }); correctly checks code and signal and logs accordingly.
  4. Final Answer:

    child.on('exit', (code, signal) => { if (code !== null) console.log(`Exited with code ${code}`); else console.log(`Terminated by signal ${signal}`); }); -> Option A
  5. Quick Check:

    Check code !== null to distinguish exit vs signal [OK]
Hint: Check if exit code is null to detect signal termination [OK]
Common Mistakes:
  • Ignoring the signal parameter in exit event
  • Using 'close' event instead of 'exit' for exit codes
  • Not checking for null exit code before logging