Understanding Unix I/O Models: Sync vs Async, Blocking vs Non‑Blocking

In a previous post I covered the Unix I/O model, and during a recent weekly meeting @fp1203 (a goldendoc member) explained the underlying implementation of poll and epoll. The discussion touched on the concepts of synchronous, asynchronous, blocking, and non‑blocking network I/O, revealing varied interpretations among participants.

Although many online articles address these concepts, most lack authoritative sources. I found an article that cites Richard Stevens' "UNIX Network Programming, Volume 1," which provides a credible definition.

I also located the English original of the book and shared it for download.

Section 6.2 of the book, which I reviewed, explains the I/O models in detail; the article I referenced is essentially a translation of this section, offering a clear explanation of sync and async I/O.

Below are the key points I gathered.

IO Models

Unix currently has five I/O models, consistent with the previous article:

Blocking I/O

Non‑blocking I/O

I/O multiplexing

Signal‑driven I/O

Asynchronous I/O

Two Stages of I/O

Waiting for data to become ready

Copying data from the kernel buffer to the user‑space buffer

Difference Between Synchronous and Asynchronous

Read the original Section 6.2 comparison of signal‑driven I/O and asynchronous I/O for details. In summary:

Synchronous I/O requires the user process to actively copy data from the kernel buffer to its own buffer.

Asynchronous I/O lets the kernel automatically copy data to the user buffer and then notifies the user.

Thus, the first four models are synchronous, while only the fifth model is truly asynchronous.

Blocking vs Non‑Blocking

Blocking and non‑blocking refer to individual processes within the five models. When using multiplexing calls like poll, the poll system call itself runs in kernel space, so the calling user process is blocked while poll executes.

Poll scans each file descriptor; to scan efficiently, each descriptor must be set to non‑blocking mode (using fcntl). When poll detects readable descriptors, it returns to the user process, indicating which fds are ready.

The user process then calls read to copy data from the kernel buffer to its own buffer—this is why poll is considered synchronous I/O.

Whether read is blocking or non‑blocking depends on the fd’s mode: if the fd is non‑blocking, read is non‑blocking; otherwise, it blocks.

In practice, once poll returns, data is already ready in the kernel buffer, so read will succeed regardless of the fd’s mode. However, if poll returns due to a timeout and a subsequent read is performed on an fd that was polled, the blocking behavior becomes significant.

Conclusion

To determine if I/O is synchronous or asynchronous, check who initiates the data copy to the user process.

Calls like select, poll, and epoll are synchronous; the invoking user process remains in a blocked state during the call.

JavaScript or Node.js network/file reads that use callbacks are asynchronous I/O.