epoll 学习踩坑：fcntl 设置非阻塞到底用 F_SETFL 还是 F_SETFD？

最近在写 epoll 聊天室小项目时遇到一个非常“隐蔽但致命”的坑：我以为设置非阻塞就是 fcntl(fd, F_SETFD, ... | O_NONBLOCK)，结果程序行为异常（ET 模式下丢事件、阻塞卡住、甚至表现得像没设置非阻塞一样）。最后才发现：设置 O_NONBLOCK 必须用 F_SETFL，不是 F_SETFD。

这篇文章记录一下这个坑的本质原因、正确写法，以及 F_SETFD 到底是干什么的。

---

1. 先说结论：设置非阻塞用 F_GETFL/F_SETFL

O_NONBLOCK 属于“文件状态标志（file status flags）”，所以只能通过 F_GETFL/F_SETFL 来获取/设置：

int flags = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, flags | O_NONBLOCK);

这也是写 epoll + EPOLLET(边缘触发) 时最重要的基础之一：ET 模式必须配合 non-blocking + 循环读到 EAGAIN，否则很容易出现“读不干净就再也不通知”的错觉。

---

2. 为什么 F_SETFD | O_NONBLOCK 不行？

原因在于 fcntl 的第二个参数决定了你在操作哪一类标志位。下面这组宏很多人都见过：

#define F_DUPFD  0   /* Duplicate file descriptor.  */
#define F_GETFD  1   /* Get file descriptor flags.  */
#define F_SETFD  2   /* Set file descriptor flags.  */
#define F_GETFL  3   /* Get file status flags.  */
#define F_SETFL  4   /* Set file status flags.  */

关键在注释：

• F_GETFD / F_SETFD：file descriptor flags（描述符标志）
• F_GETFL / F_SETFL：file status flags（状态标志）

而 O_NONBLOCK 并不属于 file descriptor flags，它属于 file status flags。

所以如果你写：

fcntl(fd, F_SETFD, fcntl(fd, F_GETFD, 0) | O_NONBLOCK);

本质上是在对“描述符标志”做 OR 运算，但 O_NONBLOCK 根本不是这套标志体系里的成员。结果通常是：

• 要么设置无效（最常见）
• 要么直接报错（取决于内核/实现）

最终表现就是：你以为 fd 变成 non-block 了，实际上它还是阻塞 fd。

---

3. 那 F_SETFD 到底是干什么的？

F_SETFD 用来设置 “文件描述符标志（file descriptor flags）”，最常见、也是最重要的一个就是：

✅ FD_CLOEXEC（close-on-exec）

含义是：当进程调用 exec()（如 execve / execlp）把自己替换成另一个程序时，这个 fd 会自动关闭，避免 fd 泄漏到新程序里。

正确用法：

int fdflags = fcntl(fd, F_GETFD);
fcntl(fd, F_SETFD, fdflags | FD_CLOEXEC);

这在服务端程序里非常常见：父进程打开了监听 socket、pipe、日志文件等，如果 fork 后子进程去 exec 启动别的程序，fd 泄漏会导致资源占用、管道 EOF 不出现、甚至安全风险。FD_CLOEXEC 就是解决这个问题的。

所以记住：
F_SETFD 是给 FD_CLOEXEC 这种“描述符级别标志”用的，不是给 O_NONBLOCK 用的。

---

4. 一句话记忆：FD vs FL

• F_GETFD/F_SETFD：管 FD 标志（例如 FD_CLOEXEC）
• F_GETFL/F_SETFL：管 FL 状态标志（例如 O_NONBLOCK）

非阻塞 → FL
close-on-exec → FD

---

5. 推荐的“通用模板”函数

写网络程序时我通常直接封装两个小函数，避免再搞混：

#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>

static void set_nonblock(int fd) {
    int flags = fcntl(fd, F_GETFL, 0);
    if (flags == -1) { perror("fcntl F_GETFL"); exit(1); }
    if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) {
        perror("fcntl F_SETFL"); exit(1);
    }
}

static void set_cloexec(int fd) {
    int flags = fcntl(fd, F_GETFD, 0);
    if (flags == -1) { perror("fcntl F_GETFD"); exit(1); }
    if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC) == -1) {
        perror("fcntl F_SETFD"); exit(1);
    }
}

---

6. 更现代的方式：创建时直接带上标志

Linux 里很多系统调用支持“创建时就设置”，减少遗漏和竞态：

• epoll_create1(EPOLL_CLOEXEC)
• accept4(..., SOCK_NONBLOCK | SOCK_CLOEXEC)
• socket(..., SOCK_CLOEXEC)（部分平台支持）

例如：

int epfd = epoll_create1(EPOLL_CLOEXEC);

这样就不用再额外 fcntl 设置 FD_CLOEXEC，更干净也更安全（尤其多线程场景下）。

---

7. 这坑为什么在 epoll/ET 里更容易被放大？

因为 ET 模式的正确姿势是：

1. fd 必须 non-block
2. 每次 EPOLLIN 触发要循环 read/accept 到 EAGAIN

如果你误用 F_SETFD，fd 其实还是阻塞的，那么：

• 你循环读时可能直接卡住
• 或者你不敢循环读，导致读不干净，下一次边沿不再触发
• 最终表现为“epoll 很奇怪”、“ET 会丢事件”
  其实根本原因是：fd 根本没变成 non-block

---

8. 总结

• 设置非阻塞：用 F_GETFL/F_SETFL + O_NONBLOCK
• 设置 close-on-exec：用 F_GETFD/F_SETFD + FD_CLOEXEC
• 学 epoll 尤其是 ET 时，先确保 non-block 真正生效，再谈“读到 EAGAIN”的正确模型