一句话 + 关键问题

一句话：不创建线程，只用一个"事件循环"反复问操作系统"哪些 I/O 已经就绪"，然后一次处理一个事件——这样就不需要锁，调度权也回到了程序手里；代价是任何处理器都绝不能阻塞，于是需要异步 I/O 和手动管理状态。

前面几章我们一直用线程 + 锁 + 条件变量/信号量写并发程序，也在第 32 章见识了它的两大麻烦：一是正确性难（忘记加锁、死锁、原子性/顺序违反）；二是程序员几乎无法控制调度——创建线程后只能"祈祷"操作系统把它们安排得合理。

本章介绍另一种并发风格：基于事件的并发（event-based concurrency）。它在 GUI 程序和一些互联网服务器里非常常见（今天的 node.js 就是代表），根源则是 C/UNIX 里的 select()/poll()。本章是并发部分的最后一章（原书标注为 Advanced）；其中"轮询还是中断"的取舍，会在下一部分第 36 章 I/O 设备里再次出现。

核心概念速览

基本思想：事件循环

事件驱动的做法简单到有点"可疑"：等某件事（事件）发生；发生后看它是什么类型，做它需要的那一点点工作（可能包括发起 I/O 请求、为以后安排别的事件等）。就这样。规范的事件服务器围绕下面这个结构构建：

while (1) {
    events = getEvents();      // 等待：哪些事情发生了？
    for (e in events)
        processEvent(e);       // 一次处理一个事件（事件处理器）
}

这里有两点非常关键：

• 处理器运行时，它是系统里唯一的活动。没有别的线程会在它执行到一半时插进来修改共享数据。
• 决定下一个处理哪个事件，就等于调度。线程程序把调度交给操作系统；事件程序自己掌握调度——这种显式控制是事件方式的根本优势之一。

剩下的大问题是：getEvents() 到底怎么知道"网络包到了""磁盘读完了"？这就轮到 select() 了。

重要的 API：select()（或 poll()）

大多数系统都提供 select() 或 poll() 系统调用。它们做的事情很简单：检查是否有需要处理的 I/O 到达。例如一个 Web 服务器想知道有没有新的网络包到了，就可以用它们。

int select(int nfds,
           fd_set *restrict readfds,    // 关心"可读"的 fd
           fd_set *restrict writefds,   // 关心"可写"的 fd
           fd_set *restrict errorfds,   // 关心"异常"的 fd
           struct timeval *restrict timeout);

手册的描述（意译）：select() 检查 readfds、writefds、errorfds 这三个描述符集合，看其中哪些已可读、可写或有异常待处理。只检查前 nfds 个描述符（0 到 nfds-1）。返回时，select() 把传入的集合替换成"已就绪的子集"，返回值是所有集合中就绪描述符的总数。

关于 select() 有两点值得注意：

1. 既能查可读，也能查可写。可读让服务器知道"新包到了、需要处理"；可写让服务器知道"现在可以回复了"（发送队列没满）。
2. 超时参数 timeout。常见用法是设为 NULL：无限期阻塞，直到某个描述符就绪。更健壮的服务器通常会指定超时；一种常见技巧是把超时设为 0，让 select() 立即返回（纯轮询，不睡眠）。

poll() 与之非常相似（传入 struct pollfd 数组而不是位图）。无论哪个，它们都给了我们构建非阻塞事件循环的基础：检查哪些包到了，从有消息的 socket 读出来，需要时回复。

使用 select()：逐行读原书 Figure 33.1

#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

int main(void) {
    // open and set up a bunch of sockets (not shown)
    // main loop
    while (1) {
        // initialize the fd_set to all zero
        fd_set readFDs;
        FD_ZERO(&readFDs);

        // now set the bits for the descriptors
        // this server is interested in
        // (for simplicity, all of them from min to max)
        int fd;
        for (fd = minFD; fd < maxFD; fd++)
            FD_SET(fd, &readFDs);

        // do the select
        int rc = select(maxFD+1, &readFDs, NULL, NULL, NULL);

        // check which actually have data using FD_ISSET()
        int fd;
        for (fd = minFD; fd < maxFD; fd++)
            if (FD_ISSET(fd, &readFDs))
                processFD(fd);
    }
}

• FD_ZERO(&readFDs)：清空集合。必须每轮都做，因为上一轮的 select() 已经把集合改写成了"就绪子集"。
• FD_SET(fd, &readFDs)：把服务器关心的描述符（比如它正在服务的所有网络 socket）加进集合。
• select(maxFD+1, &readFDs, NULL, NULL, NULL)：只关心可读；最后一个 NULL 是超时，表示"一直等到有 fd 就绪"。
• FD_ISSET(fd, &readFDs)：逐个检查哪些 fd 真的有数据，对它们调用 processFD()——这就是事件处理器。

细节：书中的两个 for 循环写的是 fd < maxFD，而 select() 的第一个参数是 maxFD+1。如果 maxFD 本身也是要监听的描述符，循环应写成 fd <= maxFD；下面的模拟器和实验代码都采用 <=。真实服务器还要处理发送消息、发起磁盘 I/O 等更多细节，可参考 Stevens & Rago 的 APUE，以及 Pai 等人、Welsh 等人对事件服务器整体流程的论述。

为什么更简单：无需加锁

在单 CPU 上运行事件驱动程序时，并发程序里那些问题都不存在了。原因很直接：同一时刻只处理一个事件，事件服务器不会被另一个线程打断——它毫无疑问是单线程的。因此不需要获取或释放锁，多线程程序里常见的并发 bug（原子性违反、顺序违反、死锁……）在基本的事件方式里不会出现。

问题：阻塞的系统调用

听起来很美：写个简单循环，事件来了就处理，连锁都不用想。但问题来了：如果某个事件需要发起一个可能阻塞的系统调用呢？

设想客户端请求服务器读一个磁盘文件并返回内容（很像一个简单的 HTTP 请求）。处理器最终要调用 open() 打开文件，再调用一串 read() 读它。只要所需的元数据或数据不在内存里，open() 和 read() 都可能向存储系统发 I/O 请求，从而花很长时间。

• 线程服务器：没问题。发起 I/O 的线程挂起等待时，其他线程照常运行，服务器继续推进。I/O 与计算的自然重叠，正是线程编程显得自然直接的原因。
• 事件服务器：没有别的线程可运行，只有主事件循环。处理器一旦阻塞，整个服务器就跟着阻塞，直到调用完成；此时系统闲着——巨大的资源浪费。所以事件系统必须遵守一条规则：不允许阻塞调用。

解决方案：异步 I/O

为克服这个限制，许多现代操作系统引入了向磁盘发起 I/O 的新方式，统称异步 I/O（asynchronous I/O）：应用发起 I/O 请求后，在 I/O 完成之前就把控制权还给调用者；另有接口让应用判断各个 I/O 是否已完成。

以 Mac 上的接口为例（其他系统类似），核心是 struct aiocb，即 AIO 控制块（AIO control block）。简化版如下：

struct aiocb {
    int             aio_fildes;   // 文件描述符 File descriptor
    off_t           aio_offset;   // 文件内偏移 File offset
    volatile void  *aio_buf;      // 结果放到哪块内存 Location of buffer
    size_t          aio_nbytes;   // 读多少字节 Length of transfer
};

int aio_read(struct aiocb *aiocbp);         // 发起异步读；成功则立即返回
int aio_error(const struct aiocb *aiocbp);  // 完成返回 0；否则返回 EINPROGRESS

接口名 aio_error() 有点让人困惑，但它确实就是"查询这个请求完成没有"。于是，对每个未完成的异步 I/O，应用都可以周期性地轮询（poll）系统。

不过，逐个检查很痛苦：如果某一时刻有几十上百个 I/O 在飞，是一直反复检查、还是先等一会儿？为此一些系统提供了基于中断（interrupt）的办法：用 UNIX 信号（signal）在异步 I/O 完成时通知应用，从而无需反复询问。这种"轮询 vs 中断"的取舍在设备层面同样存在（第 36 章）。

void handle(int arg) {
    printf("stop wakin' me up...\n");
}
int main(int argc, char *argv[]) {
    signal(SIGHUP, handle);
    while (1)
        ; // doin' nothin' except catchin' some sigs
    return 0;
}

prompt> ./main &
[3] 36705
prompt> kill -HUP 36705
stop wakin' me up...
prompt> kill -HUP 36705
stop wakin' me up...

没有异步 I/O 的系统上，纯粹的事件方式无法实现。但研究者想出了效果不错的替代方案：Pai 等人（Flash Web 服务器）描述了一种混合方案——用事件处理网络包，用线程池管理未完成的磁盘 I/O。

另一个问题：状态管理

事件方式的另一个问题是：代码通常比线程版更难写。原因如下：事件处理器发起异步 I/O 后，必须把一些程序状态打包起来，留给 I/O 完成时的下一个处理器使用。线程程序不需要这一步，因为所需状态就在线程的栈上。Adya 等人把这项工作称为手动栈管理（manual stack management），它是事件编程的根本特征。

看一个具体例子：服务器要从文件描述符 fd 读数据，读完后把数据写到网络 socket sd。线程版（忽略错误检查）简单到不值一提：

int rc = read(fd, buffer, size);   // 阻塞：线程睡眠，别的线程照跑
rc = write(sd, buffer, size);      // 醒来后 sd 就在栈上，直接用

事件版呢？先用 AIO 异步发起读，再周期性地用 aio_error() 检查完成情况。等它告诉我们"读完了"，事件服务器怎么知道接下来该干什么——写到哪个 socket？发起读的那个处理器早就返回了，它的局部变量 sd 随栈帧一起没了。

解决办法（Adya 等人）是用一个古老的程序设计语言构造：续延（continuation）。听起来复杂，其实很简单：把完成这个事件所需的信息记在某个数据结构里；事件发生（磁盘 I/O 完成）时，查出这些信息并继续处理。本例中，就是把 socket 描述符 sd 记在一张以 fd 为键的哈希表里；磁盘 I/O 完成时，事件处理器用 fd 查表得到 sd，终于可以把数据写到 socket。

// 事件版的伪代码（示意）
void on_request(int sd, const char *path) {         // 处理器①
    int fd = open(path, O_RDONLY);                   // （open 本身也可能阻塞！）
    struct aiocb *cb = make_aiocb(fd, buffer, size);
    aio_read(cb);                                    // 立即返回
    table_put(fd, (cont_t){ .sd = sd, .cb = cb });   // ← 续延：记住"之后要写给谁"
}
void on_io_done(int fd) {                            // 处理器②：aio_error()==0 或收到信号
    cont_t c = table_get(fd);                        // ← 查回状态
    write(c.sd, (void *)c.cb->aio_buf, size);
    table_remove(fd);
}

模拟器：三种服务器正面对比

把上面的讨论放进同一个场景：一批请求按时间到达，有的只需一点 CPU（数据在内存里），有的还要读磁盘。三种服务器在单 CPU上处理同一批请求：

1. 每请求一线程：线程调用阻塞 read() 时睡眠，调度器运行别的就绪线程（这里用非抢占的 FIFO 调度）。
2. 事件循环 + 阻塞 I/O：处理器直接调用阻塞 read()，整个循环卡住直到磁盘返回。
3. 事件循环 + 异步 I/O：处理器发起 aio_read()、登记续延后立即返回；I/O 完成后作为新事件排队，由另一个处理器查表并回复。

模型假设：请求 = CPU 计算 c₁ →（若需要）磁盘读 L → 回复 CPU 1 个单位；磁盘可以同时处理多个请求；事件按"就绪时间，再按请求编号"排队。"线程切换开销"只加在线程版上，用来体会线程的额外成本。

事件方式仍然困难的地方

• 多 CPU。从单 CPU 走向多 CPU 时，事件方式的一部分简单性消失了：要用上多个 CPU，事件服务器就得并行运行多个事件处理器，于是临界区等常见同步问题又出现了，也就又需要锁。在现代多核系统上，"无锁的简单事件处理"已经不再可能。
• 与系统活动（如分页）集成不好。如果事件处理器发生缺页（page fault），它就会阻塞，服务器在缺页处理完之前毫无进展。尽管服务器刻意避免了显式阻塞，这种由缺页造成的隐式阻塞很难避免，频繁时会造成严重的性能问题。
• 代码随时间难以维护。各种例程的确切语义会变化。例如某个例程从非阻塞变成阻塞，调用它的事件处理器也必须跟着改——把自己拆成两半。由于阻塞对事件服务器是灾难性的，程序员必须时刻留意所用 API 的语义变化。
• 异步磁盘 I/O 与网络 I/O 难以统一。虽然如今大多数平台都有异步磁盘 I/O，但花了很长时间才走到这一步，而且它与异步网络 I/O 的集成并不像想象中那样简单统一：我们希望只用 select() 管理所有未完成 I/O，实际上通常要把 select()（网络）和 AIO 调用（磁盘）组合起来用。

线程 vs 事件：对比表

原书的结论：事件服务器把调度控制权交给应用本身，但代价是复杂性，以及与现代系统其他部分（如分页）集成的困难。没有哪种方法胜出，线程和事件很可能会作为同一个并发问题的两种解法长期共存。

先预测再验证

动手实验：用 select() 写事件循环

cd labs/33-events && make
./pipes
./run_demo.sh 9090

[parent] child0 间隔 150ms 写 4 条，读端 fd=3
[parent] child1 间隔 250ms 写 3 条，读端 fd=4
[parent] child2 间隔 400ms 写 2 条，读端 fd=5
[ 150.8ms] select rc=1 → fd3 可读: "child0 msg0"
[ 250.9ms] select rc=1 → fd4 可读: "child1 msg0"
[ 300.9ms] select rc=1 → fd3 可读: "child0 msg1"
[ 401.1ms] select rc=1 → fd5 可读: "child2 msg0"
[ 451.0ms] select rc=1 → fd3 可读: "child0 msg2"
[ 501.0ms] select rc=1 → fd4 可读: "child1 msg1"
[ 601.2ms] select rc=1 → fd3 可读: "child0 msg3"
[ 601.2ms] fd3 EOF（child0 结束）
[ 751.2ms] select rc=1 → fd4 可读: "child1 msg2"
[ 751.2ms] fd4 EOF（child1 结束）
[ 801.3ms] select rc=1 → fd5 可读: "child2 msg1"
[ 801.3ms] fd5 EOF（child2 结束）
[parent] 全部管道关闭，事件循环结束

===== 服务器阻塞模拟 -b 0 ms =====
[client A] 5 条消息，平均 RTT = 0.24 ms，最大 RTT = 0.41 ms
[client B] 5 条消息，平均 RTT = 0.15 ms，最大 RTT = 0.19 ms
[client C] 5 条消息，平均 RTT = 0.18 ms，最大 RTT = 0.33 ms
--- 服务器日志前 12 行 ---
[server] 监听 127.0.0.1:9191，阻塞模拟 = 0 ms，listen fd = 3
[server   302.2ms] select 第 1 轮返回 rc=1，就绪: fd3
[server   302.3ms]   accept → 新连接 fd4
[server   302.3ms] select 第 2 轮返回 rc=1，就绪: fd4
[server   302.4ms]   fd4 收到 "A#0" 并回显
[server   304.9ms] select 第 3 轮返回 rc=1，就绪: fd3
[server   304.9ms]   accept → 新连接 fd5
...
===== 服务器阻塞模拟 -b 100 ms =====
[client A] 5 条消息，平均 RTT = 140.36 ms，最大 RTT = 150.58 ms
[client B] 5 条消息，平均 RTT = 240.89 ms，最大 RTT = 350.90 ms
[client C] 5 条消息，平均 RTT = 260.88 ms，最大 RTT = 400.19 ms
--- 服务器日志前 12 行 ---
[server] 监听 127.0.0.1:9191，阻塞模拟 = 100 ms，listen fd = 3
[server   303.3ms] select 第 1 轮返回 rc=1，就绪: fd3
[server   303.4ms]   accept → 新连接 fd4
[server   303.4ms] select 第 2 轮返回 rc=2，就绪: fd3 fd4
[server   303.4ms]   accept → 新连接 fd5
[server   403.6ms]   fd4 收到 "A#0" 并回显
[server   403.7ms] select 第 3 轮返回 rc=2，就绪: fd3 fd5
[server   403.7ms]   accept → 新连接 fd6
[server   504.0ms]   fd5 收到 "B#0" 并回显
[server   504.1ms] select 第 4 轮返回 rc=2，就绪: fd4 fd6
[server   604.3ms]   fd4 收到 "A#1" 并回显
[server   704.6ms]   fd6 收到 "C#0" 并回显

自测题

常见误区与小结