注:详细I/O复用详解及select、poll、epoll请前往:https://blog.csdn.net/Ambition_HAO/article/details/97024189
select:用户通过3个参数(readfds、writefds,exceptfds)分别传入感兴趣的可读、可写及异常等事件,内核通过对这些参数的在线修改来反馈其中的就绪事件。这使得用户每次调用select都要重置这3个参数。采用轮询的方式来检测就绪事件,算法的时间复杂度为O(n)
poll:同一处理所有事件类型,因此只需要一个事件集参数(struct pollfd *fds)。用户通过fd.events传入感兴趣的事件,内核通过修改pollfd.revents反馈其中就绪的事件采用轮询的方式来检测就绪事件,算法的时间复杂度为O(n)
epoll:内核通过一个事件表直接管理用户感兴趣的所有事件。因此每次调用epoll_wait时,无需反复传入用户感兴趣的事件。epoll_wait系统调用的参数events仅用来反馈就绪的事件采用回调的方式来检验就绪事件,算法的事件复杂度为O(1)。
epoll比poll和select的好处
①、select/poll返回时,内核会直接修改出传入事件集合,用于标示哪些事件就绪。所以每次调用时都要传递监控的所有socket给select/poll系统调用,也就是说要将用户态的socket列表拷贝到内核态,当监听的文件描述符数量上万的话每次都要拷贝几十几百KB的内存到内核态,效率很低。而调用epoll_wait时不用每次调用都向内核拷贝事件描述信息,它在内核中维护一个事件表,并提供一个独立的系统调用epoll_ctl来控制往其中添加 删除 修改事件。这样每次epoll_wait调用都直接从该内核事件表中取得用户注册的事件,而无须反复从用户空间读取这些事件文件描述符就会被注册到内核事件中,只有当有新的socket需要监听时,才会从用户空间拷贝。
②、select和poll采用的是轮询的机制,每次都需要将扫描一遍所有的文件描述符,并从其中找出就绪的文件描述符返回给用户。这样的话时间复杂度是O(n)。而epoll_wait则不同,它采用的是回调的机制。内核维护了一个双链表,用户存储发生的事件;当内核检测到就绪的文件描述符后,就会触发回调函数,将就绪的文件描述符对应的事件插入到内核就绪链表中。当epoll_wait调用时,仅仅观察这个list链表里有没有数据。有数据就返回,没有数据就sleep,等到超时t时间到后即使链表没数据也返回。它的时间复杂度是O(1)。
③、select和poll只能工作在低效的LT模式下,epoll支持高效的ET模式,在这种模式下,可以减少epoll_wait的调用。并且epoll还支持EPOLLONESHOT事件,该事件能进一步的减少可读、可写、异常等事件被触发的次数。