5.epoll的水平触发和边缘触发

1. socket接收缓冲区不为空 有数据可读 读事件一直触发
2. socket发送缓冲区不满 可以继续写入数据 写事件一直触发
备注：符合思维习惯，epoll_wait返回的事件就是socket的状态

1. accept一个连接，添加到epoll中监听EPOLLIN事件
2. 当EPOLLIN事件到达时，read fd中的数据并处理
3. 当需要写出数据时，把数据write到fd中；
如果数据较大，无法一次性写出，那么在epoll中监听EPOLLOUT事件
4. 当EPOLLOUT事件到达时，继续把数据write到fd中；
如果数据写出完毕，那么在epoll中关闭EPOLLOUT事件

1. socket的接收缓冲区状态变化时触发读事件，即空的接收缓冲区刚接收到数据时触发读事件
2. socket的发送缓冲区状态变化时触发写事件，即满的缓冲区刚空出空间时触发读事件
备注：仅在状态变化时触发事件

1. accept一个一个连接，添加到epoll中监听EPOLLIN|EPOLLOUT事件
2. 当EPOLLIN事件到达时，read fd中的数据并处理，read需要一直读，直到返回EAGAIN为止
3. 当需要写出数据时，把数据write到fd中，直到数据全部写完，或者write返回EAGAIN
4. 当EPOLLOUT事件到达时，继续把数据write到fd中，直到数据全部写完，或者write返回EAGAIN

1. 从ET的处理过程中可以看到，ET的要求是需要一直读写，直到返回EAGAIN，否则就会遗漏事件。
ET的编程可以做到更加简洁，某些场景下更加高效，但另一方面容易遗漏事件，容易产生bug。
2. LT的处理过程中，直到返回EAGAIN不是硬性要求，但通常的处理过程都会读写直到返回EAGAIN，
但LT比ET多了一个开关EPOLLOUT事件的步骤。
LT的编程与poll/select接近，符合一直以来的习惯，不易出错。

1.内核：收到第一个连接请求。线程 A 和 线程 B 两个线程都在 epoll_wait() 上等待。
由于采用边缘触发模式，所以只有一个线程会收到通知。这里假定线程 A 收到通知
2.线程A：epoll_wait() 返回
3.线程A：调用 accpet() 并且成功
4.内核：此时 accept queue 为空，所以将边缘触发的 socket 的状态从可读置成不可读
5.内核：收到第二个建连请求
6.内核：此时，由于线程 A 还在执行 accept() 处理，只剩下线程 B 在等待 epoll_wait()，
于是唤醒线程 B。
7.线程A：继续执行 accept() 直到返回 EAGAIN
8.线程B：执行 accept()，并返回 EAGAIN，此时线程 B 可能有点困惑(“明明通知我有事件，结果却返回 EAGAIN”)
9.线程A：再次执行 accept()，这次终于返回 EAGAIN

1.内核：接收到两个建连请求。线程 A 和 线程 B 两个线程都在等在 epoll_wait()。
由于采用边缘触发模式，只有一个线程会被唤醒，我们这里假定线程 A 先被唤醒
2.线程A：epoll_wait() 返回
3.线程A：调用 accpet() 并且成功
4.内核：收到第三个建连请求。由于线程 A 还没有处理完(没有返回 EAGAIN)，
当前 socket 还处于可读的状态，由于是边缘触发模式，所有不会产生新的事件
5.线程A：继续执行 accept() 希望返回 EAGAIN 再进入 epoll_wait() 等待，
然而它又 accept() 成功并处理了一个新连接
6.内核：又收到了第四个建连请求
7.线程A：又继续执行 accept()，结果又返回成功