开始
epoll 是 Linux 提供的 I/O event notification facility。在需要监听的 fd 数量很多（成千上万）而同一时刻可读/可写的数量又比较少（几个？几十个？几百个？）的情况下，性能要明显优于 select、poll。
API
与 epoll 直接相关的 API 有：
创建 epoll fd：epoll_create/epoll_create1
操作 epoll fd：epoll_ctl
监听 epoll fd：epoll_wait/epoll_pwait
创建
int epoll_create(int size);
int epoll_create1(int flags);
- epoll_create 用于创建一个 epoll fd。从 Linux2.6.8 开始，size 参数就被废弃了，但是使用时传入的参数必须大于0。
- epoll_create1 的参数 flags 可以为 0 或 EPOLL_CLOEXEC。
- flags 为 0：epoll_create1 的作用和 epoll_create 一样。
- flags 为 EPOLL_CLOEXEC：将返回的 epoll fd 设置为 close on exec。
操作
int epoll_ctl(int epfd, int op, int fd, struct epoll_event* event);
- 在 epfd 上设置 (op参数) 描述符 fd 的事件 (event 参数)。
- epfd 是 epoll_create 的返回值。
- fd 是想要操作的文件描述符。
- op 是操作的类型，其取值有：
- EPOLL_CTL_ADD
- EPOLL_CTL_MOD
- EPOLL_CTL_DEL
- event 是 fd 所关心的事件。对于 EPOLL_CTL_DEL，可以传 NULL（BUG：Linux2.6.9 之前不能传NULL）。
typedef union epoll_data {
void* ptr;
int fd;
uint32_t u32;
uint64_t u64;
} epoll_data_t;
struct epoll_event {
uint32_t events; // events is a bit set
epoll_data_t data;
};
- epoll_event 的成员 events 是一个 bit set。其值可以是下面各值的或。
- EPOLLINT：监听可读事件。
- EPOLLOUT：监听可写事件。
- EPOLLRDHUP ：监听对端断开连接。
- EPOLLPRI：外带数据。
- EPOLLERR：Error condition happened on the associated file descriptor.
- EPOLLHUP：Hang up happened on the associated file descriptor.
- EPOLLET：边沿触发，epoll 监听的 fd 默认是电平触发。
- EPOLLONESHOT：对应 fd 的事件被触发通知后，需要重新调用 epoll_ctl 对其进行修改(EPOLL_CTL_MOD)，才能恢复事件触发通知。
监听
int epoll_wait(int epfd, struct epoll_event* events, int maxevents, int timeout);
int epoll_pwait(int epfd, struct epoll_event* events, int maxevents, int timeout, const sigset_t* sigmask);
监听的接口比较简单，暂时没什么好介绍。
线程安全性
在知乎上看到一个问题讨论 epoll 的线程安全性，里面提到 github 上的一个 issue，有一段话：
One thread is calling
epoll_wait()and blocks there. After that another thread is adding a new file descriptor to the epoll file. Becauseepoll_wait()will not take this change into consideration, it will not be woken up on that file descriptor's events.
简单说就是，一个线程阻塞在 epoll_wait 上，另一个线程调用 epoll_ctl设置 fd 会有问题。
但是，我在 man epoll_wait 中看到的内容，却说这样做是安全的：
While one thread is blocked in a call to epoll_pwait(), it is possible for another thread to add a file descriptor to the waited-upon epoll instance. If the new file descriptor becomes ready, it will cause the epoll_wait() call to unblock.
自己简单写一个测试工具：一个线程负责 accept TCP 连接，然后调用 epoll_ctl 将新连接注册到 epoll。另一个线程负责 epoll_wait，读取 client 发送过来的数据，并简单打印出来。并没有出现，这个 github issue 提到的问题…
网上看到，一个线程负责 accept，其它线程负责 epoll_wait 的主流方案是，通过 pipe 或 eventfd 传送 fd，在负责 epoll_wait 的线程中执行注册。（同时可以通过对多个 epoll_wait的线程进行负载均衡。）
小结
最近感觉近几年 Linux 内核更新得挺快的，需要的时候还是去看对应版本的 man page 比较靠谱…
另外，学习学习就好，I/O 多路复用的事还是交给库和框架吧 ^_^
参考文档
- The method to epoll’s madness
- EPOLL_CTL_DISABLE and multithreaded applications
- libevent实现多线程，one loop per thread，多线程通信
- epoll的线程切换的问题？
- linux的epoll_wait以及epoll_ctl是否线程安全?
- 为什么epoll是线程安全？
- one loop per thread 的服务器程序，是一个线程监听一个端口吗？
- epoll_wait() is oblivious to concurrent updates via epoll_ctl()
（2018.07.29 更新“线程安全性”一节。）
