以下均为对epoll在多线程中的使用的一些笔记，如果有不对的地方，烦请指出
主要对于我所遇到的问题进行讨论，不会讨论代码如何改写，探讨如何解决这个问题
这些问题均是我在编写我的Web服务器遇到的,我在编写多线程Web服务器的时候,思考如何利用多核的优势来编写Web服务器.在学习了muduo网络库之后，我的先前一个版本的Web服务器采用这种方式,一个master线程+多个工人线程,但是我觉得在高并发的情况下只有一个线程可以accept这无疑限制了accept吞吐量,并不算利用多核优势.进而引发了我对于在多线程中如何高效合理的使用epoll有了探索.
file descriptor表 ，每个fd包含内核维护所有打开文件的file description表,每一个表都包含文件的状态标志每个进程的task_struct 包含了用于完全应该工作的成员
struct task_struct {
//文件系统信息
int link_count , total_link_count;
---
struct files_struct * files; //打开的文件信息
---
}
struct files_struct {
-----
atomic_t count; //引用技术
}
在用户态使用close() 减少一次count , 当count 为０,才会从内核的file description 删除
实际上,epoll( ) 主要是混淆了用户态的file descriptor和内核态中真正用于实现的 file description . 当进程调用close 关闭fd ，就会出现问题，也就是说我们在调用的时候，传入的是用户态的 file descriptor ,也就是平时我们所用的fd那个数字，但是在内核中，引用的是file description ,就是那个内核对象
epoll_ctl(EPOLL_CTL_ADD) 实现上并不是注册一个file descriptor(fd) , 而是将fd 和一个指向内核file description 的指针一块注册给了epoll ，也就是说epoll中管理的fd 生命周期,是内核中的相对应的file descriptor
我们可以查看最权威的man手册
Q6 Will closing a file descriptor cause it to be removed from all epoll sets automatically?
A6 Yes, but be aware of the following point. A file descriptor is a reference to an open file
description (see open(2)). Whenever a descriptor is duplicated via dup(2), dup2(2), fcntl(2)
F_DUPFD, or fork(2), a new file descriptor referring to the same open file description is created.
An open file description continues to exist until all file descriptors referring to it have been
closed. A file descriptor is removed from an epoll set only after all the file descriptors refer-
ring to the underlying open file description have been closed (or before if the descriptor is
explicitly removed using epoll_ctl() EPOLL_CTL_DEL). This means that even after a file descriptor
that is part of an epoll set has been closed, events may be reported for that file descriptor if
other file descriptors referring to the same underlying file description remain open.
同时也就是说当我们使用close去关闭掉一个fd 的时候，如果这个fd 是内核中file description的唯一引用
，内核中的 file description 同时也会跟着一起删除,这样没有什么问题，但是如果有其他引用,close并不会删除这个file descrption. 这样epoll会继续上报这个已经close掉的fd 上的事件，并且此时上次的应用程序看到的现象是关闭了fd ,但是 epoll_wait 会不断返回关闭的fd的事件信息，更为头疼的是fd已经被关闭了，我们无法通过epoll_ctl去从集合中删除掉这个fd
从Marek的博客中的代码中得到
rfd, wfd = pipe()
write(wfd, "a") # Make the "rfd" readable
epfd = epoll_create()
epoll_ctl(efpd, EPOLL_CTL_ADD, rfd, (EPOLLIN, rfd))
rfd2 = dup(rfd)
close(rfd)
r = epoll_wait(epfd, -1ms) # still recv event!!!
所以我们应该在close之前首先调用epoll_ct在epoll中删除掉相应的fd
这个问题是我思索很久的问题,如果我的web服务器在某种场景上，需要应对大量的短连接,那么我会想如何把accpet()分发到不同的CPU 上，来利用多核的能力.
1)首先我想到的方案是所有线程共用一个isten fd每一个线程创建epollfd ,把listen fd加入到所有线程的epoll 中.
2)这样说的话,将所有的线程共用一个epollfd也会引起惊群问题
- 内核：收到第一个连接请求。线程 A 和 线程 B 两个线程都在 epoll_wait() 上等待。由于采用边缘触发模式，所以只有一个线程会收到通知。这里假定线程 A 收到通知
- 线程A：epoll_wait() 返回
- 线程A：调用 accpet() 并且成功
- 内核：此时 accept queue 为空，所以将边缘触发的 socket 的状态从可读置成不可读
- 内核：收到第二个建连请求
- 内核：此时，由于线程 A 还在执行 accept() 处理，只剩下线程 B 在等待 epoll_wait()，于是唤醒线程 B
- 线程A：继续执行 accept() 直到返回 EAGAIN
.8. 线程B：执行 accept()，并返回 EAGAIN，此时线程 B 可能有点困惑(“明明通知我有事件，结果却返回 EAGAIN”)
.9. 线程A：再次执行 accept()，这次终于返回 EAGAIN
- 内核：接收到两个建连请求。线程 A 和 线程 B 两个线程都在等在 epoll_wait()。由于采用边缘触发模式，只有一个线程会被唤醒，我们这里假定线程 A 先被唤醒
- 线程A：epoll_wait() 返回
- 线程A：调用 accpet() 并且成功
- 内核：收到第三个建连请求。由于线程 A 还没有处理完(没有返回 EAGAIN)，当前 socket 还处于可读的状态，由于是边缘触发模式，所有不会产生新的事件
- 线程A：继续执行 accept() 希望返回 EAGAIN 再进入 epoll_wait() 等待，然而它又 accept() 成功并处理了一个新连接
- 内核：又收到了第四个建连请求
- 线程A：又继续执行 accept()，结果又返回成功
线程Ａ很忙但是线程B没有活干
3)说这多，那什么是正确的做法?
从epoll的角度来考虑的话,有两种做法
EPOLLEXCLUSIVE标志，这个标志会保证一个事件只有一个epoll_wait()会被唤醒，避免了"惊群效应",并且可以完美的在多个ＣＰＵ之间进行扩展EPOLLEXCLUSIVE为什么可以做到这一点? 有这个标志位的fd，会唤醒线程中的空闲队列的头一个
EPOLLONESHOT 来模拟 LT+ EPOLLEXCLUSIVE的效果SO_REUSEPORT这个socket option ，创建多个listen socket 共用一个端口号SO_REUSEPORT在TCP连接中是通过内核来选取套接字来进行接受连接SO_REUSEPORT有两种模式,热备份和负载均衡模式，当然在3.9之后，全部是负载均衡模式SO_REUSEPORT当有连接到来时，用数据包的源IP/源端口作为一个HASH函数的输入，将结果对reuseport套接字数量取模，得到一个索引，该索引指示的数组位置对应的套接字便是工作套接字。SO_REUSEPORT的好处:解决了epoll惊群问题，程序有了更好的扩展性,只有在同一个用户下相同的服务器进程才能监听同一ip:port （安全性考虑）