企业官网建设流程全解析

我最早认真啃 Linux poll 实现，是被线上一个 C 服务坑过。那服务同时管着几百路 TCP 连接和一组串口设备，最初用 select，连接数一上来就撞上 FD_SETSIZE 限制。后来换成 poll，表面问题是解决了，但压测时发现 CPU 占用高得离谱，而且偶尔还会出现“明明有数据却不醒”的怪事。从那时起我才意识到：光会调 poll 接口远远不够，不理解内核里那套等待队列和轮询循环的配合，出了问题连排查方向都没有。

这篇内容就把 poll 从设计哲学、用户态接口到内核实现完整拆开讲一遍。虽然现在很多人偏好 epoll 甚至 io_uring，但 poll 的代码路径更短、机制更直观，是理解 Linux I/O 多路复用最好的“入门解剖样本”。不管你是写应用层网络服务、搞嵌入式驱动，还是准备内核相关面试，跟着走一遍都会有收获。

1. 先回答一个问题：为什么需要 poll

1.1 从阻塞 I/O 的痛点说起

先回到最原始的模型。你写一个网络服务，最朴素的做法就是每个连接开一个线程，线程里 read() 阻塞等数据。这种方式在连接数少的时候完全没问题，逻辑清晰、写起来也爽。但连接数一旦上来，线程数量就膨胀，线程切换开销、栈内存占用、锁竞争都会成为瓶颈。

于是大家想到另一个思路：能不能让一个线程同时“看着”多个文件描述符，哪个 fd 有数据了再去处理哪个？这正是 poll 要解决的核心问题。它把“等数据”从每个 fd 各自阻塞，变成统一在一个系统调用里等待，用户进程通过一次 poll 调用，就能知道一批 fd 中哪些可读、哪些可写、哪些发生了异常。

1.2 poll 的设计目标：把“等”这件事抽象出来

poll 这个名字本身就很直白：轮流询问每个 fd 的状态。它的设计目标可以拆成三点：

• 能力上：支持一个进程同时监控多个 fd，不受 select 的 FD_SETSIZE（通常 1024）限制。
• 语义上：区分“可读”“可写”“异常”等不同事件，让调用者按需关注。
• 性能上：进程在没有任何 fd 就绪时进入睡眠，由内核在事件发生时唤醒它，而不是用户态死循环轮询。

一句话总结，poll 把“等”这个动作下沉到了内核，用户态只需要交出一组 fd 和关心的事件，剩下的等待和通知都由内核完成。这也是 select/poll/epoll 这类 I/O 多路复用机制的共同哲学：从“主动逐个查”变为“被动等待通知”。

2. 设计哲学：内核如何“通知”你，而不是让你“死等”

2.1 等待队列：内核里最朴素的“电话本”

poll 能实现“有事叫我”的核心机制，是内核的等待队列（wait queue）。可以把它理解成一份“电话本”：进程睡眠前，在它关心的设备上登记自己的联系方式；设备状态变化时，通过这个电话本挨个打电话通知所有登记的进程“起来看看”。

这里有一个关键点需要说清楚：poll 中的等待队列不是进程自己随便挂的，而是通过驱动或者文件系统实现的 poll 回调挂上去的。每个 poll 监视的 fd 背后都有一个具体的文件或设备，只有那些真正能产生事件的实体才知道自己该把“电话本”放在哪。比如一个串口驱动，它的等待队列头就放在设备结构体里；一个 socket，它的等待队列头就挂在 sock 结构上。

2.2 就绪掩码与事件语义

poll 的事件用掩码表示，每个 fd 对应一组事件位。用户通过events字段说明自己关心什么，内核和驱动通过revents字段告诉我们实际发生了什么。常用的事件包括：

这里有个容易忽略的细节：即使events里没请求 POLLERR、POLLHUP、POLLNVAL，内核依然会在revents中返回这些状态。因为错误和挂断是“强制上报”的，调用者必须处理，否则可能陷入“明明 poll 返回了，但 events 里什么都没置位”的困惑。

2.3 为什么 poll 是 O(n)：感知范围换来的实现简单

poll 在每次调用时，都需要把所有传入的 fd 从头到尾扫一遍，看看哪个就绪了。这个动作的时间复杂度是 O(n)。为什么这么设计？

因为它需要覆盖一个很通用的场景：调用者可能每次传入不同的 fd 集合。今天监控 3 个 socket，明天监控 50 个 socket，fd 还可能动态关闭、重开。为了支持这种灵活性，poll 选择了每次全量扫描的朴素实现。epoll 之所以快，本质上是把 fd 集合“注册”进内核，用红黑树维护，并用回调机制精确唤醒，避免了每次全量扫描，但代价是引入了更复杂的状态管理。

理解这一层，你就会明白：poll 的 O(n) 不是缺陷，而是设计者在“通用性”和“性能”之间做的取舍。对 fd 数量不大的场景，这个取舍很划算。

3. 用户态到底能摸到什么：poll() 接口与常见误区

3.1 pollfd、nfds、timeout 三个参数的真实含义

用户态接口长这样：

#include <poll.h> int poll(struct pollfd *fds, nfds_t nfds, int timeout);

三个参数分别解决三个问题：等哪些 fd、等多少个、等多久。

struct pollfd的核心字段如下：

struct pollfd { int fd; /* 文件描述符 */ short events; /* 关心的事件掩码 */ short revents; /* 实际发生的事件掩码，由内核填充 */ };

nfds是数组元素个数，不是字节数。很多新手在这里踩坑，把sizeof(struct pollfd)乘进去，导致内核访问越界。

timeout单位是毫秒。它有三种特殊取值：

• 大于 0：等待指定的毫秒数。
• 等于 0：立即返回，只做一次状态检查，不等待。
• 等于 -1：无限期等待，直到至少一个 fd 就绪或被信号中断。

在内核实现中，-1 会被转换成NULL的end_time，表示没有超时限制。

3.2 返回值的语义：0、正数、-1 分别意味着什么

poll 的返回值有三个分支，含意完全不同：

• 大于 0：就绪的 fd 数量。注意，这个数量是所有 fd 中revents非 0 的个数之和，不是“有数据可读的 fd 数”。
• 等于 0：超时，没有任何 fd 就绪。
• 等于 -1：出错，此时errno被设置。最常见的两种是EINTR（被信号中断）和ENOMEM（内核分配内存失败）。

我见过不少人在写循环时漏掉EINTR的处理，导致 poll 被信号打断后直接退出，服务看起来像“莫名其妙挂了”。正确姿势通常是：

do { ret = poll(fds, nfds, timeout); } while (ret < 0 && errno == EINTR);

3.3 用户态使用的典型雷区

第一个雷区是events没有初始化。如果你只设置了fd而忘记设置events，内核读到的可能是一堆随机位，驱动一看“用户什么都不关心”，干脆不登记等待队列，poll 立刻返回 0，表现就是“明明有数据却不醒”。

第二个雷区是重复使用struct pollfd时不重置revents。内核只会覆盖已就绪 fd 的revents，如果上次调用置了位，这次该 fd 没就绪，revents里的旧值可能残留，导致逻辑误判。稳妥做法是在每次 poll 前把所有revents清零，或者重新填充整个结构体。

第三个雷区是把timeout=0当成“略等一会”。它的语义是非阻塞轮询，适合检查当前是否有事件，不适合用来等数据。如果想等数据，timeout 至少要给一个正数，或者给 -1 永远等。

第四个雷区是忽略POLLNVAL。当 fd 在 poll 调用前已经被关闭时，poll 会返回 POLLNVAL。这不是错误，不会让 poll 失败，但它说明你的调用方逻辑有问题——你在监控一个已经失效的 fd。

4. 内核实现全景拆解：从系统调用到 do_poll

4.1 入口：SYSCALL_DEFINE3(poll, ...)

在 Linux 内核里，poll 的系统调用入口定义在fs/select.c。它接受用户态的struct pollfd数组指针、fd 数量和超时毫秒值，然后进入内部实现：

SYSCALL_DEFINE3(poll, struct pollfd __user *, ufds, unsigned int, nfds, int, timeout_msecs) { struct timespec64 end_time, *to = NULL; int ret; if (timeout_msecs >= 0) { to = &end_time; timespec64_add_safe(current_kernel_time64(), ms_to_timespec64(timeout_msecs), &end_time); } ret = do_sys_poll(ufds, nfds, to); ... return ret; }

这里有几个值得注意的点。第一，如果 timeout 是 -1，to保持为 NULL，表示永不超时。第二，内核把相对毫秒值转换成了绝对时间点end_time，这样在处理“被唤醒后重新等待”时，可以精确计算剩余时间，不会因为中间处理其他 fd 而“多等”。

do_sys_poll是真正的准备工作，它要做几件事：把用户态的 pollfd 数组拷贝到内核空间；根据 nfds 大小决定用栈上的内联数组还是动态分配内存；初始化 poll 等待机制；调用do_poll()进入核心循环。

注意拷贝这一步，早期内核实现是把整个数组一次性copy_from_user，但 nfds 很大时会导致拷贝开销和内存压力。所以内核里有一个N_INLINE_POLL_ENTRIES的小数组优化，少量 fd 用栈，大量 fd 才走堆分配。

4.2 poll_table：驱动与 VFS 之间的“登记簿”

要理解 poll 的内核实现，必须先理解poll_table。它本质上是一张“登记簿”，让内核在扫描每个 fd 时，能把当前进程注册到该 fd 对应的等待队列上。

关键数据结构定义在include/linux/poll.h：

typedef struct poll_table_struct { __poll_t (*_qproc)(struct file *, wait_queue_head_t *, struct poll_table_struct *); __poll_t _key; } poll_table;

在多数的内核版本中，poll_table被内嵌到struct poll_wqueues中：

struct poll_wqueues { poll_table pt; struct poll_table_page *table; struct task_struct *polling_task; int triggered; int error; int inline_index; struct poll_table_entry inline_entries[N_INLINE_POLL_ENTRIES]; };

_qproc是回调函数指针，驱动在实现 poll 回调时，会调用poll_wait()，而poll_wait()最终会调用这个_qproc。默认情况下，_qproc指向__pollwait，它的作用就是把当前进程挂到设备驱动提供的等待队列头上。

_key字段是当前这次 poll 请求关心的事件掩码。驱动可以通过poll_requested_events()拿到它，从而决定要不要把某些事件返回给用户。比如用户只关心 POLLIN，驱动就没必要在 POLLOUT 事件上唤醒进程。

4.3 do_pollfd：逐个文件描述符的体检

do_poll循环里，对每个 fd 都会调用do_pollfd()。这个函数做三件事：

1. 根据 fd 取出对应的struct file。
2. 调用vfs_poll()，也就是调用该文件实际 poll 回调。
3. 将驱动返回的事件掩码，与用户请求的events（以及强制事件）做与运算，写入revents。

它的逻辑可以简化为：

static inline __poll_t do_pollfd(struct pollfd *pollfd, poll_table *pwait, bool *can_busy_poll, ...) { int fd = pollfd->fd; __poll_t mask = 0; struct file *file; file = fget(fd); if (file == NULL) { mask = POLLNVAL; } else { mask = vfs_poll(file, pwait); fput(file); } mask &= pollfd->events | POLLERR | POLLHUP | POLLNVAL; pollfd->revents = mask; return mask; }

注意几个关键细节。第一，fget(fd)会检查 fd 是否有效，无效则直接把revents置为 POLLNVAL，而不是让整个 poll 失败。所以 poll 监控一个已经关闭的 fd 不会导致进程崩溃，只会返回一个“无效”标志。

第二，mask &= pollfd->events | POLLERR | POLLHUP | POLLNVAL这行是语义核心：只返回调用者关心的事件，但错误、挂断、无效这三类状态强制返回。

第三，pwait这个指针只在第一次调用时传入，之后会变成 NULL。这是内核的一个小优化：只有第一次轮询时才需要重新注册等待队列，之后再次轮询只是为了检查状态变化。

4.4 do_poll 主循环：等一等、再看一眼

do_poll()是 poll 机制的心脏，核心逻辑是一个 for 循环：

static int do_poll(unsigned int nfds, struct poll_list *list, struct poll_wqueues *wait, struct timespec64 *end_time) { ... for (;;) { struct poll_list *walk; int count = 0; for (walk = list; walk != NULL; walk = walk->next) { struct pollfd *pfd = walk->entries; for (int i = 0; i < walk->len; i++, pfd++) { if (do_pollfd(pfd, pt, &can_busy_loop, busy_started)) count++; pt = NULL; } } if (count || timed_out) break; if (!poll_schedule_timeout(wait, TIMED_OUT, slack)) timed_out = 1; } ... }

这个循环的模式就是典型的“检查—睡眠—再检查”。第一次扫描时，通过pt传入等待队列，让驱动有机会把当前进程注册到各个设备上。如果没有 fd 就绪，就调用poll_schedule_timeout()让进程进入睡眠。

为什么进程被唤醒后还要再扫描一遍？因为设备只是通知“我可能有你要的事件”，但具体是哪一个 fd、什么事件、是否已经被别人消费掉，都需要重新确认。这也保证了 poll 语义的正确性：返回给用户的revents一定是调用时刻的真实状态，而不是睡眠前的过期状态。

poll_schedule_timeout()内部做了几件事：

• 把当前进程状态设置为TASK_INTERRUPTIBLE。
• 调用schedule_timeout()让出 CPU，等待被唤醒或超时。
• 唤醒后立即把状态设回TASK_RUNNING。
• 如果被信号打断，返回-EINTR，表示这次睡眠不是正常结束。

注意poll_schedule_timeout()传入的是剩余时间，而不是绝对超时时间。内核在进入睡眠前已经根据end_time计算了剩余量，这样即便进程被虚假唤醒多次，也不会无限期拖长整个 poll 的等待时间。

4.5 超时控制的实现细节

超时是 poll 最容易出错的地方。前面提到，用户传入毫秒值，内核先转成绝对时间点end_time。每次准备睡眠时，通过timespec64_sub计算剩余时间，再转成相对时间传入schedule_timeout()。

但这里有一个细节很多资料不会提：poll_schedule_timeout()还接受一个slack参数。slack代表“可容忍的调度延迟”，内核根据这个值决定是否把当前进程接入高精度定时器。简单说，如果你设置了很紧的超时，内核会尝试用更精确的定时手段；如果超时很宽松，就用普通低精度定时器，减少不必要的开销。

另一个边界情况：当 timeout 等于 0 时，end_time就等于当前时间点。进入do_poll循环后，第一次扫描如果没有就绪 fd，计算剩余时间时发现已经超时，poll_schedule_timeout会立刻返回，循环退出。所以timeout=0表现为“只查一次，不等待”，这正是非阻塞轮询的语义。

当 poll 被信号打断时，内核会返回-ERESTARTNOHAND，最终在系统调用返回路径上转换成-EINTR给用户态。这里面有一个很容易让应用开发者困惑的点：poll 已经登记的等待队列怎么办？答案是内核在do_sys_poll的末尾会调用poll_freewait()清理所有挂载的等待队列节点，保证这次调用不会留下残留引用。这也意味着，poll 每次调用都会重建等待关系，这是它相比 epoll 在大量连接场景下的又一个开销来源。

5. 驱动开发者视角：在内核里实现 poll 方法

5.1 file_operations 里的 poll 回调

如果你写过字符设备驱动，一定见过file_operations结构体中有一个.poll成员。它是 poll 机制在驱动侧的唯一入口：

struct file_operations { ... __poll_t (*poll)(struct file *filp, struct poll_table_struct *wait); ... };

驱动实现 poll 回调的职责非常明确：告诉 VFS 当前设备“可读吗、可写吗、出错了没”，并在用户进程等待期间，把它挂到设备的等待队列上。

一个最常见的驱动 poll 实现骨架长这样：

static __poll_t my_device_poll(struct file *filp, poll_table *wait) { struct my_device *dev = filp->private_data; __poll_t mask = 0; poll_wait(filp, &dev->read_wait, wait); poll_wait(filp, &dev->write_wait, wait); if (dev->read_available) mask |= POLLIN | POLLRDNORM; if (dev->write_available) mask |= POLLOUT | POLLWRNORM; return mask; }

两个关键动作缺一不可：先poll_wait()登记等待，再检查设备状态返回掩码。顺序上，先调用poll_wait再查状态，可以避免“状态刚检查完，设备产生了事件，但进程还没挂上等待队列”的竞态。

5.2 poll_wait 与等待队列头的协同

poll_wait()是 VFS 提供给驱动的辅助函数，实际效果是调用poll_table中的_qproc回调，把当前进程加入驱动的等待队列。

static inline void poll_wait(struct file *filp, wait_queue_head_t *wait_address, poll_table *p) { if (p && p->_qproc && wait_address) p->_qproc(filp, wait_address, p); }

这个函数本身不做“等待”，它只是登记。驱动在poll_wait()中传入的wait_address，必须与驱动在数据到达时唤醒所用的等待队列头是同一个。如果驱动在 poll 回调里挂了read_wait，但在中断处理程序或工作队列里唤醒的是write_wait，那 poll 永远不会被唤醒。

这个问题我在实际驱动调试中踩过多次，排查思路很简单：用 strace 看 poll 阻塞后，手动往设备写数据，如果 poll 一直没有返回，基本就是等待队列头对不上。此时在内核日志里加调试信息，确认唤醒路径到底在调哪个wake_up，一对比就清楚。

5.3 唤醒时机与事件掩码的返送

当设备状态变化时，驱动需要调用wake_up_interruptible(&dev->read_wait)或者类似的唤醒函数，把睡眠中的进程叫起来。这里要注意，唤醒函数只负责叫醒进程，它并不直接告诉 poll “现在可读了”。进程被唤醒后，会重新执行do_pollfd()，再次调用驱动的 poll 回调，此时回调检查到read_available为真，返回 POLLIN，用户态才最终看到“可读”。

也就是说，驱动侧的 poll 回调和唤醒函数是“两条腿”配合的：

• poll 回调负责“汇报当前状态”。
• 唤醒函数负责“通知进程重新汇报”。

这种设计的好处是避免了状态同步问题。事件从发生到用户感知，永远以最后一次 poll 回调为准，不会出现“内核说可读但实际没数据”的脏读。

5.4 一个最小字符设备驱动示例

下面用一个非常简化的“按键设备”驱动展示完整配合。假设设备结构体里有key_pressed表示按键是否被按下，按下时中断处理函数会置位并唤醒等待队列：

struct key_dev { bool key_pressed; wait_queue_head_t wq; struct cdev cdev; }; static irqreturn_t key_isr(int irq, void *data) { struct key_dev *dev = data; dev->key_pressed = true; wake_up_interruptible(&dev->wq); return IRQ_HANDLED; } static __poll_t key_poll(struct file *filp, poll_table *wait) { struct key_dev *dev = filp->private_data; __poll_t mask = 0; poll_wait(filp, &dev->wq, wait); if (dev->key_pressed) mask |= POLLIN | POLLRDNORM; return mask; } static ssize_t key_read(struct file *filp, char __user *buf, size_t count, loff_t *pos) { struct key_dev *dev = filp->private_data; if (!dev->key_pressed) return -EAGAIN; dev->key_pressed = false; return 0; } static struct file_operations key_fops = { .owner = THIS_MODULE, .poll = key_poll, .read = key_read, };

用户态用 poll 等待按键时，内核工作流程是：poll 系统调用进入 do_poll，第一次扫描调用key_poll，poll_wait把当前进程挂到dev->wq上；此时key_pressed为假，返回 mask 为 0；do_poll 发现没有 fd 就绪，进程睡眠；按键中断到来，ISR 置位key_pressed并唤醒wq上的所有进程；进程醒来后第二次扫描再次调用key_poll，这次key_pressed为真，返回 POLLIN，poll 最终向上返回。

这个例子虽然简单，但覆盖了 poll 机制在驱动侧的全部要素：poll 回调、等待队列、唤醒函数、状态检查。理解它，其他复杂驱动的 poll 实现都是在这个骨架上做扩展。

6. poll 的瓶颈：为什么会有 epoll 和 io_uring

6.1 连接数一多，poll 为什么“力不从心”

回到我开头说的线上问题。poll 在 fd 数量中等时表现尚可，但连接数一旦过万，问题就很明显了，原因有三个。

第一，每次调用 poll，内核都必须把用户态传入的 pollfd 数组从用户空间拷贝到内核空间。连接数越多，拷贝的数据量越大。对于常驻的 TCP 连接，这个拷贝纯属浪费，因为 fd 集合几乎没变化。

第二，每次调用都要重新对全部 fd 做一轮扫描，并且重新挂等待队列。即使只有 1 个 fd 有事件，也要把所有 fd 都扫一遍，CPU 时间与 fd 总数成正比。当 fd 数量达到几万，即使大部分空闲，扫描开销依然可观。

第三，poll 的唤醒是“全量唤醒”。一个设备有数据，会唤醒所有监控它的进程；即使某个进程只关心另一个连接的事件，它也会被叫醒，然后全量扫描一遍才发现没有自己要的事件，继续睡回去。这种惊群效应在大量客户端同时活跃时会被放大。

6.2 与 select / epoll 的对比

epoll 的核心优势不在于“不用扫描”，而在于它把 fd 集合的管理从每次调用变成了注册制。fd 加入 epoll 实例后，内核持续维护它的事件关系，只有当 fd 就绪时才会放入就绪链表。epoll_wait 只需要从就绪链表里取事件，量级接近 O(就绪数)，而不是 O(总监控数)。

6.3 什么场景下 poll 反而是合适的选择

说到这，别急着淘汰 poll。它对特定场景依然是最优解之一：

• fd 数量少且变化频繁：比如临时监控一批文件描述符，用完就扔，用 poll 比 epoll 省去注册、注销的额外调用。
• 不需要长期维护 fd 集合的简单工具程序：比如命令行小工具、测试程序，poll 代码更短、意图更清晰。
• 嵌入式场景：资源受限，引入 epoll 的复杂状态不值得。
• 需要兼容老内核的环境：poll 的出现比 epoll 早得多，可移植性更好。

我个人的判断标准很简单：如果监控的 fd 数量在几百以内，poll 完全够用，代码还直观；如果面向大规模连接服务器，直接上 epoll 或 io_uring。选型的前提是了解自身场景的规模，而不是盲目追新。

7. 实战排查与经验记录

7.1 常见问题速查表

7.2 用 strace 观察 poll 的行为

排查 poll 相关问题，我最常用的工具是 strace。它能直接打印 poll 系统调用的入参和返回值，省去很多猜测。举个例子：

strace -f -e trace=poll -tt -T ./my_server

输出片段类似：

14:23:01.123456 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 1000) = 1 ([{fd=3, revents=POLLIN}])

这个输出包含三个关键信息：

• 调用时刻和耗时。
• 传入的 fd 列表和关心的事件。
• 返回的就绪 fd 和具体事件。

如果 poll 一直返回 0，说明设备确实没有产生事件，问题大概率在设备侧；如果 poll 返回 -1 EINTR，则要检查信号处理逻辑。strace 的最大价值是帮你区分“用户态逻辑问题”和“内核/驱动问题”，这一步定界比什么都重要。

7.3 几个值得记住的边界条件

第一个是nfds的上限。虽然 poll 没有 select 那样的 FD_SETSIZE 限制，但内核会受RLIMIT_NOFILE约束。如果传入的 nfds 超过进程可用的 fd 上限，内核会返回EINVAL。所以别以为 poll “无限”支持任意数量的 fd。

第二个是同一 fd 在 pollfd 数组中重复出现。内核会分别处理每个数组项，返回时就绪计数可能大于实际 fd 数量。比如同一个 fd 出现两次且都可读，poll 返回 2，而不是 1。这个行为符合“按数组项计数”的语义，但不少开发者会被坑到。

第三个是 poll 对 pipe 的特殊行为。当 pipe 的写端全部关闭后，poll 会返回 POLLHUP 或者 POLLERR，具体取决于内核版本和 pipe 状态。判断“对端是否关闭”时，不要只检查 POLLIN，还要同时检查 POLLHUP 和 POLLERR。

第四个是timeout=0时的忙循环风险。如果业务里对一批 fd 反复调用poll(fds, nfds, 0)，一旦有 fd 永远不就绪，就会形成 CPU 忙轮询。这种模式虽然合法，但非常浪费资源。需要轮询检查的场景，建议至少给一个很小的超时值，或者考虑用非阻塞 I/O 配合事件驱动。

写在最后：一点实际操作中的体会

poll 这套机制我前前后后线上线下调过很多次，最大的感受是：它没有秘密，核心就是“等待队列 + 状态检查 + 唤醒重查”三个动作的反复配合。驱动侧只要保证 poll 回调诚实报告状态、唤醒路径准确通知、等待队列头一致，用户侧基本不会出大问题。真正难缠的往往是边界情况：信号打断、fd 关闭竞态、超时精度、惊群放大。排查时不要一上来就怀疑内核，先用 strace 把 poll 的系统调用行为和返回结果看清楚，再顺着等待队列和驱动唤醒路径往下查，效率会高很多。

如果你正准备深入 epoll 或者 io_uring，把 poll 的这套实现吃透绝对不亏。epoll 的等待队列机制、就绪回调、唤醒路径，跟 poll 在底层是同一套思路，只是多了一层“实例化注册”的封装。从这个角度看，poll 不只是一段历史代码，它其实是理解整个 Linux I/O 事件通知体系的一把钥匙。