注：上图的poll不要理解成和select相似那个poll，这是通过epoll_ctl调用的。
相关视频推荐面试中正经“八股文”网络原理tcp/udp，网络编程epoll/reactor
epoll_wait中的events数组设置多大合适？
C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂
下面简要分析一下epoll的工作过程：
(1) epoll_wait调用ep_poll，当rdlist为空（无就绪fd）时挂起当前进程，知道rdlist不空时进程才被唤醒。
(2) 文件fd状态改变（buffer由不可读变为可读或由不可写变为可写），导致相应fd上的回调函数ep_poll_callback()被调用。
(3) ep_poll_callback将相应fd对应epitem加入rdlist，导致rdlist不空，进程被唤醒，epoll_wait得以继续执行。
(4) ep_events_transfer函数将rdlist中的epitem拷贝到txlist中，并将rdlist清空。
(5) ep_send_events函数（很关键），它扫描txlist中的每个epitem，调用其关联fd对用的poll方法（图中蓝线）。此时对poll的调用仅仅是取得fd上较新的events（防止之前events被更新），之后将取得的events和相应的fd发送到用户空间（封装在struct epoll_event，从epoll_wait返回）。之后如果这个epitem对应的fd是LT模式监听且取得的events是用户所关心的，则将其重新加入回rdlist（图中蓝线），否则（ET模式）不在加入rdlist。
具体代码：
/ 扫描整个txlist链表... /for (eventcnt = 0, uevent = esed->events; !list_empty(head) && eventcnt < esed->maxevents;) {/ 取出第一个成员 /epi = list_first_entry(head, struct epitem, rdllink);/ 然后从链表里面移除 /list_del_init(&epi->rdllink);/ 读取events, 注意events我们ep_poll_callback()里面已经取过一次了, 为啥还要再取? 1. 我们当然希望能拿到此刻的最新数据, events是会变的~ 2. 不是所有的poll实现, 都通过等待队列传递了events, 有可能某些驱动压根没传 必须主动去读取. /revents = epi->ffd.file->f_op->poll(epi->ffd.file, NULL) &epi->event.events;if (revents) {/ 将当前的事件和用户传入的数据都copy给用户空间, 就是epoll_wait()后应用程序能读到的那一堆数据. /if (__put_user(revents, &uevent->events) || __put_user(epi->event.data, &uevent->data)) {/ 如果copy过程中发生错误, 会中断链表的扫描, 并把当前发生错误的epitem重新插入到ready list. 剩下的没处理的epitem也不会丢弃, 在ep_scan_ready_list() 中它们也会被重新插入到ready list /list_add(&epi->rdllink, head);return eventcnt ? eventcnt : -EFAULT;}eventcnt++;uevent++;if (epi->event.events & EPOLLONESHOT)epi->event.events &= EP_PRIVATE_BITS;else if (!(epi->event.events & EPOLLET)) {/ If this file has been added with Level Trigger mode, we need to insert back inside the ready list, so that the next call to epoll_wait() will check again the events availability. At this point, noone can insert into ep->rdllist besides us. The epoll_ctl() callers are locked out by ep_scan_ready_list() holding "mtx" and the poll callback will queue them in ep->ovflist. // 嘿嘿, EPOLLET和非ET的区别就在这一步之差呀~ 如果是ET, epitem是不会再进入到readly list, 除非fd再次发生了状态改变, ep_poll_callback被调用. 如果是非ET, 不管你还有没有有效的事件或者数据, 都会被重新插入到ready list, 再下一次epoll_wait 时, 会立即返回, 并通知给用户空间. 当然如果这个 被监听的fds确实没事件也没数据了, epoll_wait会返回一个0, 空转一次. /list_add_tail(&epi->rdllink, &ep->rdllist);}}}
说明：
l epoll_wait返回的条件是rdlist不空，而使rdlist不空的途径有两个，分别对应图中的红线和蓝线。
l ET和LT模式下的epitem都可以通过红线方式加入rdlist从而唤醒epoll_wait，但LT模式下的epitem还可以通过蓝线方式重新加入rdlist唤醒epoll_wait。所以ET模式下，fd就绪（通过红线加入rdlist）只会被通知一次，而LT模式下只要满足相应读写条件就返回就绪（通过蓝线加入rdlist）。
l ET事件发生仅通知一次的原因是只被添加到rdlist中一次，而LT可以有多次添加的机会。
1.2 两种加入rdlist途径的不同下面我们来分析一下图中两种将epitem加入rdlist方式（也就是红线和蓝线）的区别。
l 红线：fd状态改变是才会触发。那么什么情况会导致fd状态的改变呢？
对于读取操作：
(1) 当buffer由不可读状态变为可读的时候，即由空变为不空的时候。
(2) 当有新数据到达时，即buffer中的待读内容变多的时候。
对于写操作：
(1) 当buffer由不可写变为可写的时候，即由满状态变为不满状态的时候。
(2) 当有旧数据被发送走时，即buffer中待写的内容变少得时候。
l 蓝线：fd的events中有相应的时间（位置1）即会触发。那么什么情况下会改变events的相应位呢？
对于读操作：
(1) buffer中有数据可读的时候，即buffer不空的时候fd的events的可读为就置1。
对于写操作：
(1) buffer中有空间可写的时候，即buffer不满的时候fd的events的可写位就置1。
说明：红线是时间驱动被动触发，蓝线是函数查询主动触发。
【文章福利】：
ET和LT的触发方式
分析了ET和LT的实现方式，那么分析他们的触发方式就容易多了。我们通过实现分析知道LT模式下epoll_wait被唤醒可以通过两种方式（图中红线和蓝线），而ET模式只能通过一种方式（图中红线）。所以ET模式下能被唤醒的情况,LT模式下一定也能被唤醒。我们先来讨论特殊情况（ET模式）,再来讨论一般情况（LT模式）。
2.1 ET根据上一节对两种加入rdlist途径的分析，可以得出ET模式下被唤醒（返回就绪）的条件为：
l 对于读取操作：
(1) 当buffer由不可读状态变为可读的时候，即由空变为不空的时候。
(2) 当有新数据到达时，即buffer中的待读内容变多的时候。
另外补充一点：
(3) 当buffer中有数据可读（即buffer不空）且用户对相应fd进行epoll_mod IN事件时（具体见下节内容）。
对于情况(1)(2)分别对应图1(a),图1(b)。
l 对于写操作：
(1) 当buffer由不可写变为可写的时候，即由满状态变为不满状态的时候。
(2) 当有旧数据被发送走时，即buffer中待写的内容变少得时候。
另外补充一点：
(3) 当buffer中有可写空间（即buffer不满）且用户对相应fd进行epoll_mod OUT事件时（具体见下节内容）。
对于情况(1)(2)分别对应图2(a),图2(b)。
图1 ET读触发的两种情况
图2 LT写触发的两种情况
2.2 LT
LT模式下进程被唤醒（描述符就绪）的条件就简单多了，它包含ET模式的所有条件，也就是上述列出的六中读写被唤醒的条件都是用于LT模式。此外，还有更普通的情况LT可以被唤醒，而ET则不理会，这也是我们需要注意的情况。
l 对于读操作
当buffer中有数据，且数据被读出一部分后buffer还不空的时候，即buffer中的内容减少的时候，LT模式返回读就绪。如下图所示。
l 对于写操作
当buffer不满，又写了一部分数据后扔然不满的的时候，即由于写操作的速度大于发送速度造成buffer中的内容增多的时候，LT模式会返回就绪。如下图所示。
注：poll和select都是LT模式。
ET的读操作实例分析首先看程序一，这个程序想要实现的功能是当用户从控制台有任何输入操作时，输出”hello world！
”
程序一
#include <unistd.h>#include <iostream>#include <sys/epoll.h>using namespace std;int main(void){ int epfd,nfds; struct epoll_event ev,events[5];//ev用于注册事件，数组用于返回要处理的事件 epfd=epoll_create(1);//只需要监听一个描述符——标准输入 ev.data.fd=STDIN_FILENO; ev.events=EPOLLIN|EPOLLET;//监听读状态同时设置ET模式 epoll_ctl(epfd,EPOLL_CTL_ADD,STDIN_FILENO,&ev);//注册epoll事件 for(;;) { nfds=epoll_wait(epfd,events,5,-1); for(int i=0;i<nfds;i++) { if(events[i].data.fd==STDIN_FILENO) cout<<"hello world!"<<endl; } }}
运行结果：
程序一中对标准输入的监听使用ET模式，结果实现了我们想要的功能。那么实际原理是如何呢，我们将过程分析一下：
(1) 当用户输入一组字符，这组字符被送入buffer，字符停留在buffer中，又因为buffer由空变为不空，所以ET返回读就绪，输出”hello world！
”。
(2) 之后程序再次执行epoll_wait，此时虽然buffer中有内容可读，但是根据我们上节的分析，ET并不返回就绪，导致epoll_wait阻塞。（底层原因是ET下就绪fd的epitem只被放入rdlist一次）。
(3) 用户再次输入一组字符，导致buffer中的内容增多，根据我们上节的分析这将导致fd状态的改变，是对应的epitem再次加入rdlist，从而使epoll_wait返回读就绪，再次输出“hello world！
”。
我们在看看LT的情况如何，将程序一以下修改：
ev.events=EPOLLIN;//默认使用LT模式
运行结果：
结果正如我们所料，程序出现死循环，因为用户输入任意数据后，数据被送入buffer且没有被读出，所以LT模式下每次epoll_wait都认为buffer可读返回读就绪。导致每次都会输出”hello world！
”。下面在看程序二。
l 程序二
#include <unistd.h>#include <iostream>#include <sys/epoll.h>using namespace std;int main(void){ int epfd,nfds; char buf[256]; struct epoll_event ev,events[5];//ev用于注册事件，数组用于返回要处理的事件 epfd=epoll_create(1);//只需要监听一个描述符——标准输入 ev.data.fd=STDIN_FILENO; ev.events=EPOLLIN;//使用默认LT模式 epoll_ctl(epfd,EPOLL_CTL_ADD,STDIN_FILENO,&ev);//注册epoll事件 for(;;) { nfds=epoll_wait(epfd,events,5,-1); for(int i=0;i<nfds;i++) { if(events[i].data.fd==STDIN_FILENO) { read(STDIN_FILENO,buf,sizeof(buf));//将缓冲中的内容读出 cout<<"hello world!"<<endl; } } }}
运行结果：
程序二依然使用LT模式，但是每次epoll_wait返回读就绪的时候我们都将buffer（缓冲）中的内容read出来，所以导致buffer再次清空，下次调用epoll_wait就会阻塞。所以能够实现我们所想要的功能——当用户从控制台有任何输入操作时，输出”hello world！
”。我们再来看看程序三。
程序三
int main(void){ int epfd,nfds; struct epoll_event ev,events[5];//ev用于注册事件，数组用于返回要处理的事件 epfd=epoll_create(1);//只需要监听一个描述符——标准输入 ev.data.fd=STDIN_FILENO; ev.events=EPOLLIN|EPOLLET;//使用默认LT模式 epoll_ctl(epfd,EPOLL_CTL_ADD,STDIN_FILENO,&ev);//注册epoll事件 for(;;) { nfds=epoll_wait(epfd,events,5,-1); for(int i=0;i<nfds;i++) { if(events[i].data.fd==STDIN_FILENO) { cout<<"hello world!"<<endl; ev.data.fd=STDIN_FILENO; ev.events=EPOLLIN|EPOLLET;//使用默认LT模式 epoll_ctl(epfd,EPOLL_CTL_MOD,STDIN_FILENO,&ev);//重新MOD事件（ADD无效） } } }}
程序三依然使用ET，但是每次读就绪后都主动的再次MOD IN事件，我们发现程序再次出现死循环，也就是每次返回读就绪。这就验证了上一节讨论ET读就绪的第三种情况。但是注意，如果我们将MOD改为ADD，将不会产生任何影响。别忘了每次ADD一个描述符都会在epitem组成的红黑树中添加一个项，我们之前已经ADD过一次，再次ADD将阻止添加，所以在次调用ADD IN事件不会有任何影响。
