epoll之ET与LT模式

在使用epoll时，在函数 epoll_ctl中如果不设定，epoll_event 的event默认为LT（水平触发）模式。

使用LT模式意味着只要fd处于可读或者可写状态，每次epoll_wait都会返回该fd，这样的话会带来很大的系统开销，且处理时候每次都需要把这些fd轮询一遍，如果fd的数量巨大，不管有没有事件发生，epoll_wait都会触发这些fd的轮询判断。

         在ET模式下，当有事件发生时，系统只会通知你一次，即在调用epoll_wait返回fd后，不管这个事件你处理还是没处理，处理完没有处理完，当再次调用epoll_wait时，都不会再返回该fd，这样的话程序员要自己保证在事件发生时要及时有效的处理完该事件。例如：fd发生了IN事件，在调用epoll_wait后发现了该事件，程序员要保证在本次轮询中对该fd做了读操作，且还要循环调用recv操作，直到读到的recv的返回值小于请求值，或者遇到EAGAIN错误，否则，在下次轮询时，如果该fd没有再次触发事件，你就没有机会知道这个fd需要处理。这样就会增加程序员的负担和出错的机会（可能有些数据没有来得及处理，丢失数据）。

         在LT模式下，无论fd是否有事件发生，或者还有一些事件没有处理完，每次调用epoll_wait时，总会得到该fd让你处理（只要有没事件没有处理，会一直通知你处理，直到你处理完为止，这样就保证了数据的不丢失）。

         操作系统在LT模式下维护的就绪队列大小相对于ET模式肯定大，且LT轮询所有的fd总比ET轮询的fd大。自然在性能上LT不如ET，但是在使用ET模式的时，需要循环调用recv,send等处理函数，得保证其事件处理完毕，这样也会带来开销且容易出错。

从 kernel 代码来看，ET/LT模式的处理逻辑几乎完全相同，差别仅在于 LT模式在 event 发生时不会将其从 ready list 中移除，略为增大了event 处理过程中 kernel space 中记录数据的大小。

 

总结：

1. epoll 的 ET和 LT 模式处理逻辑差异极小，性能测试结果表明常规应用场景中二者性能差异可以忽略。
2. 使用 ET 的程序比使用LT 的逻辑复杂，出错概率更高。
3. ET 和LT 的性能差异主要在于 epoll_wait 系统调用的处理速度，是否是程序的性能瓶颈需要视应用场景而定，不可一概而论。

声明：本文转自http://blog.csdn.net/feitianxuxue/article/details/17078179，如转载，请说明出处。