Mastering Linux I/O Models: Blocking, Non‑Blocking, and Asynchronous Explained

I/O Overview

I/O encompasses memory, network, and disk operations, but in practice the focus is on network I/O (socket reads) and disk I/O (file reads). Each I/O request consists of two stages: first, the kernel loads data from disk into its buffer (a relatively long wait); second, the kernel copies the buffered data into the process’s address space (a short copy).

Web Request Processing Flow

The complete request path can be summarized as:

Client sends a request to the server’s NIC.

The NIC hands the packet to the kernel.

The kernel maps the packet to the appropriate socket and wakes the user‑space web server process.

The web server issues a system call to obtain the requested resource (e.g., an image).

If the resource resides on local disk, the kernel contacts the disk driver.

The kernel reads the data from the disk.

The data is placed in the kernel’s cache and the server is notified.

The server copies the data from the kernel cache to its own buffer.

The server forms a response and issues another system call to send it back.

The kernel transmits the response via the NIC.

The NIC delivers the response to the client.

This sequence involves two distinct I/O phases: network I/O for the client request and disk I/O for the server’s resource retrieval.

Key Terminology: Blocking vs. Non‑Blocking

Blocking means the I/O call does not return until the operation is fully completed; the calling thread is suspended and consumes no CPU time during the wait.

Non‑Blocking means the I/O call returns immediately with a status (e.g., EWOULDBLOCK) if data is not yet available, allowing the caller to continue other work and poll later.

Key Terminology: Synchronous vs. Asynchronous

Synchronous communication requires the caller to wait for a response before proceeding. It can be combined with blocking or non‑blocking behavior.

Asynchronous communication lets the kernel notify the caller via signals, callbacks, or status changes once the I/O completes, so the caller never blocks waiting for the result.

I/O Model Types

The five classic I/O models are:

Blocking I/O : Both wait and copy phases block the caller.

Non‑Blocking I/O : The call returns immediately; the caller must poll until data arrives.

I/O Multiplexing (select/poll) : The process blocks in select or poll until one of several descriptors becomes ready, then performs a normal read/write.

Signal‑Driven I/O (SIGIO) : The kernel sends a SIGIO signal when data is ready; the process can continue work in the meantime.

Asynchronous I/O (AIO) : The kernel handles the entire operation and notifies the application via a completion event or callback, providing fully non‑blocking behavior.

Blocking I/O

When an application calls recvfrom, it blocks until the kernel has fetched the data and copied it into user space. The thread remains inactive for the entire duration of the I/O operation.

Non‑Blocking I/O

The call returns immediately with EWOULDBLOCK if no data is ready. The application must repeatedly issue the request (polling), which can waste CPU cycles.

I/O Multiplexing (select/poll)

The process blocks inside select or poll waiting for any of a set of file descriptors to become ready. Once a descriptor is ready, the process performs a normal read/write.

Signal‑Driven I/O (SIGIO)

The application registers a signal handler for SIGIO. If data is not yet ready, the call returns; when the kernel later receives data, it sends the signal, allowing the handler to invoke recvfrom and process the data.

Asynchronous I/O (AIO)

The application issues an I/O request and immediately regains control. The kernel performs the operation entirely in the background and, upon completion, notifies the application via a status update or callback.

Comparison of the Five Models

Visual diagrams (Chinese and English) illustrate that as we move from blocking to fully asynchronous models, the amount of time spent blocked decreases, theoretically improving efficiency. The first three models (blocking, non‑blocking, multiplexing) are synchronous; the last two (signal‑driven, asynchronous) are truly asynchronous.