Single-threaded non-blocking I/O concept in Node.js - Step-by-Step Execution

Concept Flow - Single-threaded non-blocking I/O concept

Start single thread

↓

Receive I/O request

↓

Start I/O operation asynchronously

↓

Continue running other code

↓

I/O operation completes

↓

Callback/event handler runs

↓

Process I/O result

↓

Loop back to wait for more events

The single thread starts an I/O operation without waiting, continues other work, and later handles the I/O result via a callback.

Execution Sample

Node.js

const fs = require('fs');
console.log('Start');
fs.readFile('file.txt', (err, data) => {
  console.log('File read');
});
console.log('End');

This code logs 'Start', starts reading a file asynchronously, logs 'End', then logs 'File read' when the file is done.

Execution Table

Step	Action	Output	Thread State	Callback Queue
1	Run console.log('Start')	'Start'	Running main thread	Empty
2	Call fs.readFile (async start)	No output	Starts async I/O	Empty
3	Run console.log('End')	'End'	Main thread continues	Empty
4	I/O completes	No output	Main thread idle or running other code	Callback for readFile queued
5	Process readFile callback	'File read'	Callback runs on main thread	Empty

💡 All code and callbacks processed, no more events to handle

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
Callback Queue	Empty	Empty	Contains readFile callback	Empty

Key Moments - 3 Insights

Why does 'End' print before 'File read' even though readFile is called first?

Because fs.readFile starts an asynchronous operation and does not block the thread. The main thread continues to run and prints 'End' before the file reading finishes and the callback runs (see steps 2 and 3 in execution_table).

Does Node.js use multiple threads to read the file?

No, the main JavaScript thread is single-threaded. The file reading happens asynchronously using system threads or the OS, but the JavaScript code runs on one thread. The callback runs back on the main thread (see thread state in steps 2 and 5).

What happens if the callback takes a long time to run?

Since the callback runs on the single main thread, it blocks other JavaScript code from running until it finishes. This can delay other events or callbacks (implied by the single-threaded nature in the concept_flow).

Visual Quiz - 3 Questions

Look at the execution_table, what is printed at Step 3?

A 'End'

B 'File read'

C 'Start'

D No output

💡 Hint

Check the Output column at Step 3 in the execution_table

At which step does the callback for reading the file get queued?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the Callback Queue column in the execution_table

If the callback took a long time to run, what would happen to the thread state at Step 5?

A Main thread would start a new thread for the callback

B Main thread would be blocked running the callback

C Main thread would run other callbacks simultaneously

D Main thread would pause and wait for I/O

💡 Hint

Refer to the key_moments explanation about single-threaded callback execution

Concept Snapshot

Single-threaded non-blocking I/O in Node.js:
- JavaScript runs on one thread.
- I/O operations start asynchronously and do not block.
- Main thread continues running other code.
- When I/O finishes, callback is queued.
- Callback runs on main thread, can block if long.
- Enables efficient handling of many I/O tasks.

Full Transcript

In Node.js, JavaScript runs on a single thread. When an I/O operation like reading a file is requested, Node.js starts it asynchronously without waiting. This means the main thread keeps running other code, like logging 'End'. When the I/O finishes, its callback is added to a queue. The main thread then runs this callback, printing 'File read'. This approach avoids blocking the thread during slow I/O, allowing efficient multitasking. However, since callbacks run on the single thread, long callbacks can block other code. This is the core of Node.js's single-threaded non-blocking I/O model.