epoll水平/边缘触发模式下阻塞/非阻塞EPOLLOUT事件触发条件及次数

时间:2024-03-01 21:12:09

epoll水平/边缘触发模式下阻塞/非阻塞EPOLLOUT事件触发条件及次数

在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 水平触发(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