<干货来袭系列>之二：epoll的两种工作方式：LT ET

       深深地愧疚，时隔多日，才写了当初答应好的文章。并不是因为懒，而是因为真的觉得要写一个东西得花费点时间，花费点精力，不断考证，知道自己真正理解了其中的含义，才能用笔头写出来。虽然最近在忙着公司实习这边的项目，但是还是想用周天这一晚上来总结下之前打算写的<干货来袭系列>之二：epoll的两种工作方式：LT   ET，所以，闲话就不多说了，开始吧~

       相信大家看完上一篇的<干货来袭系列>之一：select poll epoll，也已经体会到了epoll功能的强大，并且据我所知，在socket编程时大多数人会采用epoll。当然了，epoll的两种工作方式LT和ET模式，这两种工作方式的选择得根据需要而定，不能盲目的只选择ET或LT模式。下面就分别说说这两种工作模式吧~

        LT（Level Trigger，水平触发）是默认的工作方式，并且同时支持阻塞和非阻塞socket，在这种模式下epoll相当于一个效率较高的poll。对于采用LT工作模式的文件描述符，当epoll_wait检测到其上有时间发生并将此事件通知应用程序后，应用程序可以不立即处理该事件，这样，当应用程序下一次调用epoll_wait时，epoll_wait还会再次相应应用程序通告此事件，直到该事件被处理。可能这时候你就会问了，如果应用程序只调用了一次epoll_wait呢？那事件会阻塞吗？答案是那是不可能滴，其实在epoll_wait的底层实现中，epoll_wait如果检测到事件，就将所有就绪的时间从内核事件表中复制到它的第二个参数events指向的数组中，内核会告诉应用程序有一个文件描述符已经就绪，然后就对这个文件描述符的fd进行I/O操作，如果不进行任何操作，内核会继续通知应用程序有就绪的文件描述符，直到被处理；还有一个原因就是在epoll_wait函数中有一个超时timeout，通过设置timeout来决定内核对事件处理的快慢程度，0是立即处理，-1是不确定，有的人也说是永久阻塞。

       ET（Edge Trigger，边沿触发）是一种高效的模式，只支持非阻塞socket。对于采用ET模式的文件描述符，当epoll_wait检测到其上有事件发生并将此时间通知应用程序以后，应用程序可以不立即处理该事件，因为后续的epoll_wait将不再向应用程序通知这一事件。 想必你也已经知道了，为什么将ET称为高效的工作方式了吧？其实就是因为ET不用多次触发，减少了每次epoll_wait可能需要返回的fd数量，在并发event数量极多的情况下能够加快epoll_wait的处理速度。

       看了这么多文字大家可能会说，你把ET说的那么好？何以见得它的高效呢？光说不练也不行啊，接下来上一段代码，虽然是书上的源码，但是我加了一些自己对代码的理解，希望看到这篇文章的大家或多或少能帮助你们一点，当然了，如果有什么地方理解的有问题，烦请各位指出，小妹不胜感激~

上面的文字是之前整理好的，但是，文字终归是文字，理论终归是理论，还是需要代码来见证它的真实性的

代码我放在了我自己的github上面，如果有需要，可以查看，github地址是：https://github.com/cuijiaojiaofendou/LTandETmodel

下图为epoll在LT模式下的监听方式

这张图中可以看出，epoll_wait会多次向应用程序通知此事件，直到该事件被执行。

下图为epoll在ET模式下的监听方式

这张图中可以看出epoll_wait检测到有事件发生时，仅仅只是向应用程序通知一次该事件，后期将不再管理这个事件是不是被执行了。

       可能epoll的两种工作方式LT和ET还有其他的不同或相同之处，也许是我自己还没有接触到的吧，如果看到这篇文章的你看到哪里有不对的地方，也希望能指出，大家相互学习，共同进步！

未来的路很长，我们一直在路上。。。