Understanding Linux I/O Models: From Blocking to Asynchronous

1. Basic Concepts

Five I/O models are covered: blocking I/O, non‑blocking I/O, I/O multiplexing, signal‑driven I/O, and asynchronous I/O.

First, understand several key system‑call functions and basic concepts.

1.1 Simple Introduction to System Call Functions

Because the author is not familiar with C, the listed system functions are referenced from other articles; corrections are welcome.

recvfrom

Linux provides this system interface for receiving network I/O. It receives a message from a socket and works for both connection‑oriented and connectionless sockets.

If the return value is <0 and errno is EWOULDBLOCK or EAGAIN (socket marked non‑blocking and the receive operation blocked or timed out), the connection is normal; the call blocks receiving data (this is crucial, the first four I/O models all rely on this call).

select

The select system call allows a program to wait for input arrival or output completion on multiple underlying file descriptors. It stores descriptors in an array (default 2048 on 64‑bit machines). When data is ready, it cannot tell which stream is ready, so it must iterate, giving O(n) time complexity.

poll

poll

stores descriptors in a linked list with no length limit. Its essence is the same as select, also O(n).

epoll

Event‑driven; when a stream is ready, the kernel notifies the specific event, so no iteration is needed, achieving O(1) complexity.

sigaction

Used to set signal handling; Linux uses SIGIO to implement asynchronous I/O notification.

1.2 Synchronous & Asynchronous

Synchronous I/O means the user process triggers an operation and waits or polls for readiness. Asynchronous I/O means the process triggers the operation and continues doing other work; when the I/O completes, the kernel notifies the process, requiring CPU support.

1.3 Blocking & Non‑blocking

Blocking I/O causes read/write calls to wait until data is ready; non‑blocking I/O returns immediately with a status value.

2. Blocking I/O Model

When a process performs a blocking read, it issues a system call, the kernel prepares the data, copies it to user‑space, and the process remains blocked until the copy completes.

The execution flow: the process calls the I/O function, the kernel prepares data, copies it to the user buffer, and the process stays blocked until the data is ready.

3. Non‑Blocking I/O Model

The process periodically polls the kernel (e.g., every 5 minutes) to check if data is ready. While waiting, the process can perform other work; the kernel returns immediately if data is not ready.

The process experiences two phases: a waiting‑for‑data phase (non‑blocking, polling) and a data‑copy phase (blocking).

4. I/O Multiplexing Model

Similar to a queue at a fast‑food restaurant, the server registers interest in multiple sockets and uses select, poll, or epoll to wait for any of them to become ready.

When a socket is ready, the kernel notifies the process, which then handles that socket while other sockets remain monitored.

5. Signal‑Driven I/O Model

Analogous to receiving a phone call when a delivery arrives, the kernel sends a signal (e.g., SIGIO) when data is ready; the process catches the signal and reads the data.

The model has two stages: data‑preparation (non‑blocking, kernel notifies) and data‑copy (blocking).

6. Asynchronous I/O Model

After issuing the I/O request, the process can immediately continue other work. When the kernel finishes preparing and copying the data, it notifies the process, and no blocking occurs in either phase.

Characteristics:

The two phases of asynchronous I/O never block the read/write operation; the kernel handles them.

When finished, the kernel places data in a buffer and notifies the application to retrieve it.

Conclusion

In terms of efficiency: blocking I/O < non‑blocking I/O < I/O multiplexing < signal‑driven I/O < asynchronous I/O. Regarding sync vs. async, only the asynchronous model is truly asynchronous; the others are synchronous.