IO多路复用之select、poll、epoll详解

select、poll、epoll都可以实现多路IO复用。

select

select是最早出现的方式：

1. 它可监控的文件描述符数量最多是1024个，
2. 每次进行调用都要将全部描述符从应用进程缓冲区复制到内核缓冲区中，
3. 返回的结果中不会具体声明哪些描述符已经就绪，还需要进行轮询查找

poll

poll
监控描述符的数量没有了限制，但其他缺点和select一样

epoll

epoll

1. 没有监控数量限制
2. 只需要将描述符从进程缓冲区向内核缓冲区拷贝一次
3. 不需要轮询查询哪些就绪，epoll返回后直接告诉进程哪些描述符已经就绪
4. epoll仅仅适用于linux OS

int epoll_create(int size);

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；

int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

epoll工作原理：

epoll_ctl用于向内核注册新的描述符或者改变某个文件描述符的状态，已经注册的描述符在内核中会被维护在一颗红黑树上，通过回调函数内核会将IO准备好的描述符假如到一个链表中管理，进程调用epoll_wait()便可以得到时间完成的描述符

epoll的工作模式

1.LT （水平触发）模式
当epoll_wait()检测到描述符事件到达时，将此事件通知进程，进程可以不立即处理该时间，下次调用epoll_wait()会再次通知进程，是默认的一种模式，并且同时支持Blocking和No-Blocking

2.ET（边缘触发）模式
描述符事件通知后，进程必须立马处理，下次调用epoll_wait不会重复通知。
很大程度上减少了epoll事件被重复触发的次数，因此效率要比lt模式高，只支持no-blocking，以避免阻塞读/阻塞写操作把多个文件描述符的任务饿死？

应用场景

很容易产生一种错觉认为只要用 epoll 就可以了，select 和 poll 都已经过时了，其实它们都有各自的使用场景。

1. select 应用场景

select 的 timeout 参数精度为 1ns，而 poll 和 epoll 为 1ms，因此 select 更加适用于实时性要求比较高的场景，比如核反应堆的控制。

select 可移植性更好，几乎被所有主流平台所支持。

2. poll 应用场景

poll 没有最大描述符数量的限制，如果平台支持并且对实时性要求不高，应该使用 poll 而不是 select。

3. epoll 应用场景

只需要运行在 Linux 平台上，有大量的描述符需要同时轮询，并且这些连接最好是长连接。

需要同时监控小于 1000 个描述符，就没有必要使用 epoll，因为这个应用场景下并不能体现 epoll 的优势。

需要监控的描述符状态变化多，而且都是非常短暂的，也没有必要使用 epoll。因为 epoll 中的所有描述符都存储在内核中，造成每次需要对描述符的状态改变都需要通过 epoll_ctl() 进行系统调用，频繁系统调用降低效率。并且 epoll 的描述符存储在内

总结：

两种工作不是很理解，特别是为什么ET模式不能使用blocking IO

欢迎扫码或微信搜一搜【第四单元】关注我，一起学习进步