select和epoll的前世今生
#2022有你相伴#
了解IO多路复用应该对epoll和select不陌生吧。
首先，select是有缺陷的，就是当事件发生(调用select）的时候，都需要在用户态和内核态之间拷贝fd数组，要知道用户态和内核态之间进行内存的拷贝是非常昂贵的，如果有上万级别的并发网络需要处理的时候，服务器根本处理不来。
这时候，Linux内核的开发者应该算是简单又粗暴的增加了一个内核调用，就是epoll了，有时候简单粗暴的东西还是能提高效率的。
先来看select接口 ：
select是用来等待fd状态的改变，核心就是定义一组fds，如果fds中的某一个fd的状态改变（比如变得可读、可写、或者异常等），select就会从等待中返回。
可以理解为这个东西必须要靠一个fd的改变才能让系统调用去等待，先别思维跳跃，我们一步一步的分析下去，它的手段我觉得肯定是让这个系统调用等在一个等待队列wait_queue上，在不需要执行任务的时候，我们就让任务进程休眠，直到条件改变时，我们再唤醒它。
通俗的说就是：你是餐饮店里唯一的一个的服务员，当店里没有顾客或者有顾客但是没有请求的时候，你处于空闲状态，就可以做点自己的事情(比如玩玩手机），当有顾客来有需求的时候你再过去服务。
如果店里来了10个顾客，有10个顾客(10个fd)都需要监控处理，哪个顾客有请求就要立即去处理，我们先抛开内核是怎么实现的，这时候能想到有两种办法：
招10个服务员对老板来说是需要成本的，所以创建10个线程也是需要成本的。
如果你有两个核，那么创建10个线程毫无意义，大家都知道线程是有时间片的，如果某一个fd的改变去处理只处理到一半，这时候这个线程的时间片用完了，就会切换到另一个线程执行，这个切换不仅增加了成本，而且毫无意义。
还不如只创建两个线程，每个线程只处理一组fds中的一半，处理完一个请求，再去处理另一个请求。不过如果是在用户态是做不了这件事的，只有调度器去搞定。这样你就只能等待在多个fd上，哪个fd请求，就去处理哪一个，处理完再去看看有没有下一个fd需要请求。
然而，如果随着fd的数量的不断增加，效率就会变得越来越低。
总之，对于select，应该没有什么好办法了，应该只能做到这样了，如果你觉得可能某一天，select实现了更高效的算法呢？
我觉得应该不会的，select接口已经那样了。我们只能接受select这个接口的缺陷，明明知道会带来限制，我们就知道去规避这个缺陷，知道什么情况下使用它。
再来看看epoll接口：
从接口看，和select接口几乎差不多的，区别主要是select主要是线性遍历fd数组去找就绪的fd，而epoll是把就绪的fd（epollfd）放在一个链表里，不需要遍历全部fd，这样就减少了不少开销。
我们来简单想一下：把原来select的大部分接口封装在epoll上，其实不是很难，epoll需要调用epoll_create创建epollfd，那么我们改成select自动创建epollfd，然后调用epoll_ctl把数组的fds设置进去，然后调用epoll_wait就可以了。
当然我只是简单想一下而已，初衷是想告诉大家：
再从内核的角度我们简单想一下：一开始应该会想到epoll和select应该是复用同一个内核的吧。实际上，它们都是独立的，一个在fs/select.c中实现，一个在fs/eventpoll.c中实现。
整体来看，select和epoll本质是一个东西，epoll有一个比较明显的改进是增加了两个对文件描述符的操作的模式： 水平触发 (LT:level trigger）和 边缘触发 (ET:edge trigger）。
现在，对于select和epoll就会形成一种理解： epoll是对select的升级，在fds比较多的情况下，优先考虑使用epoll。
当我们分析epoll和select的时候，我们不能直接跳跃到内核看是怎么实现的，应该看它的整个逻辑来分析，脑子里要形成一些疑问，就比如select已经存在的缺陷是什么？但是又有什么好处？epoll为什么改进？改进了是不更好了？还有没有值得优化的地方？通过整个分析理解下来就能更加了解epoll和select。
你也可以继续阅读 点击 以下文章，下面是我推荐给大家的几篇文章：
1.《竟然把通信协议讲的如此通俗？》
2.《彻底明白Linux硬链接和软链接》
3.《浅析Makefile、make、cmake》
4.《常见硬件通信(SPI、I2C、CAN、USB、UART)协议介绍》
