blocking I/O 的作用
在终端里执行 yes 会发生什么？
打开一个 xterm 终端，输入 yes 然后回车，你会看到满屏的 y 疯狂刷过。
yes 是一个很简单的程序，它做的事情就是不断地输出 y 加换行。但是你有没有想过一个问题： yes 生成数据的速度远远快于 xterm 能处理的速度。
xterm 可不只是一个"显示文字的窗口"。每收到一行输出，xterm 需要：
- 解析这些文字（可能包含颜色、光标移动等控制序列）
- 更新自己的帧缓冲区（frame buffer）
- 与 X server 通信来滚动窗口内容
- 最终把像素画到屏幕上
这是一大堆工作！而 yes 只需要不停地调用 write(2) 往外吐数据就行了。
那问题来了：一个跑得飞快，一个处理得慢，为什么系统没有崩溃？为什么数据没有丢失？这两个程序是怎么"配合"起来的？
答案就藏在一个叫 blocking I/O （阻塞式 I/O）的机制里。
操作系统做了什么？
秘密在于 yes 和 xterm 之间并不是直接通信的。它们之间隔着一个"伪终端"（PTY，Pseudo Terminal），而伪终端在操作系统内核中维护着一个*固定大小的缓冲区*。
你可以把它想象成一个水池：=yes= 从一头往里灌水，=xterm= 从另一头放水。水池的容量是有限的。
yes ──写入──▶ [ 内核缓冲区 (固定大小) ] ──读取──▶ xterm
关键来了：当这个缓冲区*满了*的时候，=yes= 再试图往里写数据会发生什么？
答案是：不报错，不丢数据，而是*阻塞*（block）。
具体来说， yes 程序通过 write(2) 这个*系统调用*（system call，即程序向内核请求服务的接口）来写入数据。当缓冲区满时， write(2) 不会立刻返回，而是让 yes 进程进入一种叫"可中断睡眠"（interruptible sleep）的状态。 yes 就这样"睡着了"，直到 xterm 从缓冲区中读走了一些数据，腾出了空间，内核才会把 yes 唤醒，让它继续写入。
整个过程对 yes 来说是完全透明的——它根本不知道自己曾经"睡"过。它只知道：我调用了 write(2) ，数据写出去了，仅此而已。
这就是 blocking I/O 的核心思想： 当消费者来不及处理时，让生产者自动"等一等"，而不需要任何一方写额外的协调代码。
顺便提一句，如果一个程序在打开文件时特别指定了"非阻塞模式"（non-blocking I/O），那么缓冲区满时 write(2) 不会阻塞，而是立即返回一个 EAGAIN 错误码，告诉程序"现在写不进去，你等会儿再来吧"。但这需要程序自己处理重试逻辑，显然没有阻塞模式来得省心。
亲自看看阻塞过程
光说不练假把式。我们可以做一个简单的实验，亲眼观察 blocking I/O 的效果。
实验步骤
- 打开两个终端窗口。在第一个终端中运行：
timeout 10 strace -c yes
可以看到结果：
strace: Process 9917 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 99.99 9.543729 1161 8214 write 0.00 0.000265 265 1 execve 0.00 0.000135 12 11 mmap 0.00 0.000080 10 8 2 openat 0.00 0.000038 12 3 mprotect 0.00 0.000030 5 6 fstat 0.00 0.000027 4 6 close 0.00 0.000021 21 1 munmap 0.00 0.000018 6 3 brk 0.00 0.000016 5 3 read 0.00 0.000011 5 2 pread64 0.00 0.000009 9 1 1 access 0.00 0.000006 6 1 getrandom 0.00 0.000005 5 1 arch_prctl 0.00 0.000005 5 1 futex 0.00 0.000005 5 1 prlimit64 0.00 0.000005 5 1 rseq 0.00 0.000004 4 1 set_tid_address 0.00 0.000003 3 1 set_robust_list ------ ----------- ----------- --------- --------- ---------------- 100.00 9.544412 1154 8266 3 total
- 在第二个终端中运行
timeout 10 strace -c yes >/dev/null
strace: Process 9854 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 1.304275 2 440603 write 0.00 0.000000 0 3 read 0.00 0.000000 0 6 close 0.00 0.000000 0 6 fstat 0.00 0.000000 0 11 mmap 0.00 0.000000 0 3 mprotect 0.00 0.000000 0 1 munmap 0.00 0.000000 0 3 brk 0.00 0.000000 0 2 pread64 0.00 0.000000 0 1 1 access 0.00 0.000000 0 1 execve 0.00 0.000000 0 1 arch_prctl 0.00 0.000000 0 1 futex 0.00 0.000000 0 1 set_tid_address 0.00 0.000000 0 8 2 openat 0.00 0.000000 0 1 set_robust_list 0.00 0.000000 0 1 prlimit64 0.00 0.000000 0 1 getrandom 0.00 0.000000 0 1 rseq ------ ----------- ----------- --------- --------- ---------------- 100.00 1.304275 2 440655 3 total
很明显可以看出都是10s中的运行时间，write的耗时和次数差距明显。
不只是伪终端
上面说的虽然是伪终端（PTY）的例子，但同样的机制也适用于真实的硬件终端。
假设我们通过串口连接了一台老式终端。串口的传输速度由*波特率*（baud rate）决定——波特率表示每秒传输的位数。比如 9600 baud 大约相当于每秒传输 960 个字节。
而 yes 生成数据的速度轻松就能达到每秒几万甚至几十万字节，远远超过 9600 baud。
怎么办？还是老办法：内核的串口驱动也有缓冲区。当缓冲区满了， yes 的 write(2) 就会阻塞，等待数据慢慢通过串口发送出去后，再继续写入。
所以你看，无论是伪终端还是串口，blocking I/O 都在做同一件事： 让快速的生产者自动适配慢速的消费者，而不需要应用程序自己实现任何限速逻辑。
yes 程序的代码里没有任何关于"我该跑多快"的逻辑。它就是傻乎乎地不停 write(2) ，剩下的全交给了操作系统。
缓冲区没满也能阻塞？
到目前为止，我们看到的阻塞都是因为缓冲区满了。但要是告诉你，即使缓冲区还有空间，也能主动让 TTY 进入阻塞状态呢？
听起来有点奇怪？但确实有这个需求。
想象一台老式的 VT-100 终端。我们刚刚通过串口给它发送了一个复杂的控制序列，让它执行滚屏操作。这时候终端忙于滚屏，根本来不及处理新到的数据。虽然串口物理上还在以 9600 baud 的速率传输，但终端内部的缓冲区快满了。
这种时候，终端需要告诉操作系统："停一停，我处理不过来了。"
怎么告诉？通过发送一个特殊的字节。
我们已经知道，TTY 可以对某些特殊字节做特殊处理。比如按 Ctrl+C 时，终端不会把 ^C 这个字符传给应用程序，而是向应用程序发送一个 SIGINT 信号（也就是中断信号）。
类似的，TTY 也可以配置两个特殊字节来控制数据流：
^S（ASCII 码 19）— 表示"停止发送"（stop）^Q（ASCII 码 17）— 表示"恢复发送"（start）
当终端发送 ^S 时，操作系统会暂停向该 TTY 的写入操作——即使内核缓冲区还没满，任何试图 write(2) 的进程都会被阻塞。直到终端发送 ^Q ，数据流才会恢复。
这个机制叫做 流控 （flow control）。
这就是为什么你有时在终端里不小心按了 Ctrl+S ，终端就像"死"了一样——它不是真的死了，只是 flow control 生效了，所有输出都被暂停了。这时候只要按 Ctrl+Q 就能恢复正常。这也是新手常遇到的困惑之一。
还有一种"暂停"
到目前为止，我们认识了两种让写入操作暂停的情况：
- 缓冲区满了 —
write(2)阻塞，进程进入睡眠状态，等缓冲区有空间后自动恢复 - Flow control — 终端发送
^S=，=write(2)同样阻塞，等终端发送^Q后自动恢复
这两种情况都是*阻塞*（blocking）：进程只是"睡了一觉"，条件满足后自动醒来继续工作，整个过程对程序是透明的。
但还有一种不同的"暂停"方式：当你把一个程序放到后台运行，它如果试图向终端写入数据，收到的不是阻塞，而是一个叫 SIGTTOU 的信号。这个信号会把*整个进程组*都挂起（suspend），而不仅仅是让当前进程睡一觉。你需要用 fg 命令把它拉回前台，它才能继续运行。
类似地，后台进程试图从终端*读取*数据时，会收到 SIGTTIN 信号，同样导致整个进程组被挂起。
为什么 UNIX 的设计者要发明 SIGTTOU 和 =SIGTTIN=，而不是简单地用阻塞 I/O 来处理呢？我的猜测是：TTY 驱动作为负责作业控制（job control）的组件，它的设计目标是管理*整个作业*（job），而不是作业中的单个进程。所以当一个后台作业不该读写终端时，TTY 驱动选择把整个作业挂起来，而不是只阻塞其中一个进程。
UNIX 设计哲学的缩影
回顾我们讨论的内容，你会发现这些机制都体现了 UNIX 的设计哲学：
- 让简单的事情保持简单 —
blocking I/O让程序不需要自己处理速率匹配的问题。yes的代码里没有任何限速逻辑，但它在任何速度的终端上都能正常工作。 - 做一件事做好 — TTY 驱动专注于管理终端的输入输出和作业控制，而不关心具体是什么程序在使用它。
- 关注点分离 —
yes不需要知道自己在跟 xterm 通信还是跟串口终端通信。它只管调用write(2)，剩下的交给操作系统处理。这种分层设计让每一层都保持简单。
所以下次你在终端里运行一个命令时，不妨想一想：在那些看似理所当然的输入输出背后，操作系统默默地做了多少协调工作。
