TCP的并发处理epoll

上节介绍了Socket的select并发机制,正如文中所说,select在描述符比较多时性能不够好,因为每次都要去操作所有的fd,Linux上提供了另一个高性能的并发机制,即epoll,epoll是怎么去避免select的问题的呢?

epoll有三个函数,epoll_create,epoll_ctl,epoll_wait。

epoll_create会将需要监控的fd放到集合中,不需要像select那样每次都拷贝,epoll_ctl会为fd设置一个就绪表,然后epoll_wait就去检测这个就绪表即可,不需要检测所有的fd,如果就绪表为空,表示没有事件,而select则需要遍历所有fd后才能知道没有事件,所以epoll的效率方面比select高。

epoll的使用方法和select类似,如果熟悉select那么使用epoll也不成问题,唯一需要注意的一点是EpollEvent.events这个参数,它表示你要监控添加fd的哪些事件以及监听方式,

events可以是以下几个宏的集合:
EPOLLIN :表示对应的文件描述符可以读(包括对端SOCKET正常关闭);
EPOLLOUT:表示对应的文件描述符可以写;
EPOLLPRI:表示对应的文件描述符有紧急的数据可读(这里应该表示有带外数据到来);
EPOLLERR:表示对应的文件描述符发生错误;
EPOLLHUP:表示对应的文件描述符被挂断;
EPOLLET: 将EPOLL设为边缘触发(Edge Triggered)模式,这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT:只监听一次事件,当监听完这次事件之后,如果还需要继续监听这个socket的话,需要再次把这个socket加入到EPOLL队列里
LT模式(默认):当epoll_wait检测到描述符事件发生并将此事件通知应用程序,应用程序可以不立即处理该事件。下次调用epoll_wait时,会再次响应应用程序并通知此事件。




ET模式:当epoll_wait检测到描述符事件发生并将此事件通知应用程序,应用程序必须立即处理该事件。如果不处理,下次调用epoll_wait时,不会再次响应应用程序并通知此事件。
ET模式在很大程度上减少了epoll事件被重复触发的次数,因此效率要比LT模式高。epoll工作在ET模式的时候,必须使用非阻塞套接口,以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

程序示例:

epoll可以一次检测到多个描述符变化,返回值表示有多少个描述符变化了,可以轮询这个返回值获取多个数据。

最后更新于

这有帮助吗?