epoll水平/边缘触发模式设置阻塞/非阻塞IO事件触发条件及次数

在IO多路复用技术中，epoll默认的事件触发模式为Level_triggered（水平触发）模式，即当被监控的文件描述符上有可读/写事件发生时，epoll_wait()会通知处理程序去读写。如果没有把数据一次性全部读写完(如读写缓冲区太小)，那么下次调用 epoll_wait()时，它还会通知在上没读写完的文件描述符上继续读写，当然如果你一直不去读写，会一直通知！如果系统中有大量你不需要读写的就绪文件描述符，而它们每次都会返回，这样会大大降低处理程序检索自己关心的就绪文件描述符的效率。

Edge_triggered（边缘触发）：当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。如果这次没有把数据全部读写完(如读写缓冲区太小)，那么下次调用epoll_wait()时，它不会通知你，也就是它只会通知一次，直到该文件描述符上出现第二次可读写事件才会通知！这种模式比水平触发效率高，系统不会充斥大量你不关心的就绪文件描述符！

阻塞IO：当读一个阻塞的文件描述符时，如果在该文件描述符上没有数据可读，那么它会一直阻塞在调用函数那里，直到有数据可读。当你去写一个阻塞的文件描述符时，如果在该文件描述符上没有空间(通常是缓冲区)可写，那么它会一直阻塞，直到有空间可写。以上的读和写统一指在某个文件描述符进行的操作，不单单指真正的读数据，写数据，还包括接收连接accept()，发起连接connect()等操作。

非阻塞IO：当你去读写一个非阻塞的文件描述符时，不管可不可以读写，它都会立即返回，返回成功说明读写操作完成了，返回失败会设置相应errno状态码，根据这个errno可以进一步执行其他处理。它不会像阻塞IO那样，进程阻塞在函数调用那里不动。

注意：epoll在不设置EPOLLET时，默认的事件触发模式为水平触发模式；socket在不设置非阻塞（nonblock）参数时，默认是阻塞的。

　　1）设置边缘触发：ev.events = EPOLLOUT | EPOLLET;

　　2）设置非阻塞：int flag = fcntl(cfd, F_GETFL); flag |= O_NONBLOCK; fcntl(cfd, F_SETFL, flag);

以下是在Linux操作系统下，为了得出在水平触发模式下阻塞IO、水平触发模式下非阻塞IO、边缘触发模式下阻塞IO以及边缘触发模式下非阻塞IO中EPOLLOUT事件的触发条件和相应的触发次数所做的四组对比分析实验（服务端读取数据均采用循环读取，因此水平触发模式下和边缘触发模式下都能将数据完整读取）：

1 水平触发（LT）模式结合阻塞IO（block）

可以看出在这种模式下，程序会阻塞在epoll_wait()函数这里，只有客服端有新的数据发送到服务端，EPOLLOUT事件（伴随着EPOLLIN事件）才会触发：

　　1）读缓冲区能够一次存放客户端发送过来的数据时，只触发一次EPOLLOUT事件。

　　2）读缓冲区不能一次存放客户端发送过来的数据时，会多次触发EPOLLOUT事件，直到读完客服端发送过来的数据。

2 水平触发（LT）模式结合非阻塞IO（nonblock）

在水平触发模式下，采用非阻塞IO情况下，程序不会阻塞在epoll_wait()这里，而是只要客服端与服务端建立的连接可用，即使客服端没有发送数据，EPOLLOUT事件也会一直触发（写缓冲区可写）。

3 边缘触发（ET）模式结合阻塞IO（block）

采用边缘触发模式，在阻塞IO的情况下，客服端发送过来的数据小于读缓冲区大小时，程序会一直阻塞在recv()函数（具体时间转入sk_wait_data函数，直到客户端有新数据发送过来或者达到超时才会跳出此函数）这里，导致程序无法进行下一步操作。

4 边缘触发（ET）模式结合非阻塞IO（nonblock）

边缘触发模式下采用非阻塞IO，具体地说，采用边缘触发模式必须使用非阻塞IO，不然读缓冲区数据没有读满就会一直阻塞在recv()函数这里；改成了非阻塞IO之后，当读缓冲区数据没有读满或者读到的数据为空时，recv()函数就会返回errno代码EAGAIN 或者 EWOULDBLOCK，进而做相应的后续处理。这里采用了循环读取数据处理，因此在边缘触发模式下，只要客服端发送过来的数据没有一次读完，会循环读取直到读取结束。

具体代码参见：https://gitlab.com/JC_peng/epoll_test