Master the 4 I/O Models and 5 Network Service Patterns for Efficient Backend Design

1. Four Theoretical I/O Models

Caller (service process):

Blocking: the process issues an I/O call and is suspended until the operation completes, unable to perform other work.

Non‑blocking: the process issues an I/O call and can continue executing other tasks while the operation is pending.

Callee (system‑call I/O operation):

Synchronous: the function does not return until the I/O operation finishes.

Asynchronous: the function returns immediately with an incomplete status; the kernel notifies the caller when the operation completes.

Combining these dimensions yields four models:

Synchronous blocking

Synchronous non‑blocking (rarely used)

Asynchronous blocking

Asynchronous non‑blocking – true asynchronous I/O

2. Five Network Service I/O Models

1) Synchronous blocking model

The worker process calls an I/O library function, blocks while the kernel reads data from disk into kernel space, then blocks again while the library copies data from kernel space to user space, finally returning the data to the process.

2) I/O multiplexing (synchronous blocking model) – select(), poll()

The worker calls a special library function that can manage multiple I/O requests simultaneously. Although the call blocks, it blocks on many descriptors at once, improving efficiency. The second phase still requires the worker to copy data from kernel to user space and remains blocking.

3) Synchronous non‑blocking (blind‑waiting model)

The worker calls an I/O function and can continue processing other tasks while periodically checking whether the I/O has completed. The second phase still requires the worker to copy data from kernel space to user space and remains blocking.

4) Event‑driven model (synchronous non‑blocking) – epoll(), kqueue()

The worker calls an I/O function and does not wait; when the kernel finishes the I/O it notifies the process via an event. The second phase still requires the worker to copy data from kernel to user space and remains blocking.

5) Full asynchronous I/O: AIO calls

Full async 1: The worker calls an I/O function, does not wait, and the kernel notifies the process when the I/O completes. The second phase is handled by the library, which copies data from kernel space to user space and returns the result without further involvement from the worker.

Full async 2: After kernel‑space I/O completes and notifies the process, the second phase avoids copying by using memory‑mapped I/O (mmap).

These models can be implemented with the libevent library.