Understanding Blocking, Non‑Blocking, and Multiplexed I/O: When Does Your App Wait?

Introduction

In the book "Unix Network Programming" five I/O models are mentioned: blocking I/O, non‑blocking I/O, I/O multiplexing, signal‑driven I/O, and asynchronous I/O. This article introduces basic I/O concepts and focuses on blocking I/O, non‑blocking I/O, and I/O multiplexing.

1. What is I/O

Computer perspective: Any data transfer between the CPU/memory and external devices is I/O. Two aspects: I/O devices (e.g., printer, mouse, keyboard) and reading/writing data to those devices.

Program perspective:

Modern operating systems divide memory into user space and kernel space.

User space: applications run here with limited privileges and cannot directly access kernel space or hardware.

Kernel space: core of the OS, managing processes, memory, drivers, files, network, etc.

Operating systems prevent applications from directly accessing hardware; applications must use OS APIs for safe access.

Summary: I/O for applications means indirect access via system calls to the kernel.

Application I/O access consists of two phases:

I/O call phase: application makes a system call.

I/O execution phase: kernel performs the I/O and returns.

2. Blocking I/O Model

Blocking I/O is the most common model. The flowchart is shown below.

When an application calls recvfrom, it blocks until the kernel has data ready, copies it to user space, and then returns success.

Advantages: simple model, low implementation difficulty, suitable for low concurrency.

Disadvantages: both call and execution phases block.

Typical example: data = socket.read() If the kernel data is not ready, the socket thread blocks in read() waiting for data.

Analogy: you order a milk tea and must wait without doing anything else until it is ready.

3. Non‑Blocking I/O Model

In non‑blocking I/O, the process repeatedly polls the kernel to check if data is ready; while waiting, it can perform other work.

Advantages: simple, the process is not blocked while waiting for data.

Disadvantages: polling consumes CPU resources.

Analogy: you order a milk tea, then wander the mall, periodically asking the server if it is ready.

4. I/O Multiplexing Model

Non‑blocking I/O requires many processes to poll, wasting resources. Instead, a selector (select) can monitor multiple I/O descriptors.

Multiple processes register their I/O with a selector; select blocks until any descriptor becomes readable, then the process performs recvfrom.

Note: the I/O multiplexing model blocks both in the select call and during data copy.

Advantages: suitable for high‑concurrency applications.

Disadvantages: more complex, higher development difficulty.

Analogy: a waiter (select) checks all customers' orders; when one is ready, the waiter notifies that customer.

Conclusion

When learning I/O models, understand their relationships: blocking I/O can block for long periods; non‑blocking I/O avoids blocking while waiting; I/O multiplexing reduces server pressure and excels when many connections have small messages.