Understanding Linux I/O Models: Blocking, Non‑blocking, Multiplexing, Signal‑driven, and Asynchronous

1. Basic Concepts

The five I/O models are blocking I/O, non‑blocking I/O, I/O multiplexing, signal‑driven I/O, and asynchronous I/O. Understanding the related system calls (e.g., recvfrom , select , poll , epoll , sigaction ) and the notions of synchronous vs. asynchronous and blocking vs. non‑blocking is essential.

1.1 Simple Introduction to System Calls

recvfrom

Receives a message from a socket, applicable to both connection‑oriented and connection‑less sockets. A return value < 0 with EWOULDBLOCK or EAGAIN indicates a non‑blocking socket where the receive operation would block.

select

Allows a process to monitor multiple file descriptors for readiness. It stores descriptors in an array (default limit 2048 on 64‑bit systems) and checks them sequentially, giving O(n) complexity.

poll

Similar to select but stores descriptors in a linked list, removing the fixed size limitation while retaining O(n) complexity.

epoll

Event‑driven mechanism that notifies exactly which descriptor is ready, achieving O(1) complexity.

sigaction

Sets up signal handling; Linux uses SIGIO for asynchronous I/O notification.

1.2 Synchronous & Asynchronous

Synchronous I/O blocks the calling process until the operation completes, while asynchronous I/O lets the process continue and receives a notification when the operation finishes.

1.3 Blocking & Non‑blocking

Blocking calls wait until data is ready; non‑blocking calls return immediately with a status indicating whether data is available.

2. Blocking I/O Model

In blocking I/O, the process issues a system call and waits for the kernel to copy data from kernel space to user space, remaining idle (blocked) until the data is ready.

3. Non‑blocking I/O Model

The process repeatedly polls the kernel; if data is ready, it copies it (blocking phase), otherwise it continues other work (non‑blocking phase).

4. I/O Multiplexing Model

Uses select , poll , or epoll to monitor many sockets. The kernel blocks in the multiplexing call while the application processes ready sockets without blocking on each individually.

5. Signal‑driven I/O Model

The kernel sends a signal (e.g., SIGIO ) when data is ready; the application handles the signal and then copies the data, combining a non‑blocking preparation phase with a blocking copy phase.

6. Asynchronous I/O Model

The kernel performs the entire I/O operation and notifies the application upon completion, allowing the process to perform other work throughout both phases.

7. Java BIO, NIO, AIO

Java wraps these OS models:

7.1 BIO – Synchronous Blocking

Each connection is handled by a dedicated thread; suitable for a small, fixed number of connections.

7.2 NIO – Synchronous Non‑blocking

Based on event‑driven design; uses Selector , Channel , and Buffer . A thread is allocated only when data is available.

Key NIO Components

Buffer : User‑space container for data, with explicit flip/clear operations.

Channel : Bidirectional conduit for reading/writing.

Selector : Registers channels and notifies when they are ready.

7.3 AIO – Asynchronous Non‑blocking

Application calls read / write and the kernel completes the operation in the background, notifying the application when done.

Conclusion

From efficiency perspective: Blocking I/O < Non‑blocking I/O < I/O multiplexing < Signal‑driven I/O < Asynchronous I/O. Only the asynchronous model is truly asynchronous; the others are synchronous in nature.