Blocking I/O
The thread stops and waits until the I/O finishes.
Run→Wait for I/O→Run
More waiting requests usually require more threads or remain in a queue.
Systems & OS
Blocking vs Non-Blocking I/O Simulator
Compare thread pools and event loops under the same workload, then inspect queues, I/O activity, and completion time.
The difference in one glance
Start with what happens while an I/O operation is unfinished.
Non-Blocking I/O
The event loop handles other requests while I/O is pending.
Run→Request I/O→Returns immediately→Run
One event loop can coordinate many pending requests without waiting on each one.
Detailed simulator
Workload settings
Tune the workload, then run both models together.
01 Thread pool
Thread waits
Blocking I/O
A thread stays occupied while I/O is in progress.
ACTIVE
0
QUEUED
0
DONE
0
THREAD POOL
0.00 s
Waiting request queue
02 Worker pool
Control returns
Non-Blocking with I/O Multiplexing
Workers return after starting I/O and can process other runnable work.
WORKERS
IDLE
I/O
0
DONE
0
WORKER THREADS + ASYNC I/O
0.00 s
I/O in progress
Ready / callback activity
Timeline
Start / CPU workThread blocked by I/OFree for other workHandle completion
Step mode
Use Previous and Next to inspect important events.
Simulation result
Compare both models under the same workload.
Run the simulator to generate an explanation.
Actual performance depends on the runtime, operating system, scheduler, device, protocol, and implementation.
Blocking vs Non-Blocking
Blocking keeps the calling execution context waiting. Non-blocking returns control while the operation progresses elsewhere.
Synchronous vs Asynchronous
This is a different axis describing how completion is observed or delivered; the terms are not exact synonyms.
CPU-bound vs I/O-bound
Non-blocking designs help most when elapsed time is dominated by I/O waiting. They do not remove CPU work.
I/O multiplexing
I/O multiplexing allows a single thread to monitor many sockets or file descriptors and respond only when one of them becomes ready, rather than dedicating a blocked thread to every connection. select and poll check the supplied descriptors for read, write, or error readiness, but their scanning overhead can increase as the number of descriptors grows. On Linux, epoll keeps registered descriptors in the kernel and reports ready events, making it more efficient for servers and other applications that manage large numbers of concurrent connections.