select和epoll的前世今生

了解IO多路复用应该对epoll和select不陌生吧。

首先，select是有缺陷的，就是当事件发生(调用select）的时候，都需要在用户态和内核态之间拷贝fd数组，要知道用户态和内核态之间进行内存的拷贝是非常昂贵的，如果有上万级别的并发网络需要处理的时候，服务器根本处理不来。

这时候，Linux内核的开发者应该算是简单又粗暴的增加了一个内核调用，就是epoll了，有时候简单粗暴的东西还是能提高效率的。

先来看select接口：

int select (int maxfd + 1,fd_set *readset,fd_set *writeset,fd_set *exceptset,const struct timeval * timeout);

select是用来等待fd状态的改变，核心就是定义一组fds，如果fds中的某一个fd的状态改变（比如变得可读、可写、或者异常等），select就会从等待中返回。

可以理解为这个东西必须要靠一个fd的改变才能让系统调用去等待，先别思维跳跃，我们一步一步的分析下去，它的手段我觉得肯定是让这个系统调用等在一个等待队列wait_queue上，在不需要执行任务的时候，我们就让任务进程休眠，直到条件改变时，我们再唤醒它。

通俗的说就是：你是餐饮店里唯一的一个的服务员，当店里没有顾客或者有顾客但是没有请求的时候，你处于空闲状态，就可以做点自己的事情(比如玩玩手机），当有顾客来有需求的时候你再过去服务。

如果店里来了10个顾客，有10个顾客(10个fd)都需要监控处理，哪个顾客有请求就要立即去处理，我们先抛开内核是怎么实现的，这时候能想到有两种办法：

1. 轮询，但是轮询就会占用无效的轮询时间。
2. 不轮询，不轮询那只能同步等待，如果要保证每一个顾客（fd)的请求都能做到立即处理，就需要安排十个服务员(10个线程），每个服务员(线程）分别对应一个顾客(fd）。

招10个服务员对老板来说是需要成本的，所以创建10个线程也是需要成本的。

如果你有两个核，那么创建10个线程毫无意义，大家都知道线程是有时间片的，如果某一个fd的改变去处理只处理到一半，这时候这个线程的时间片用完了，就会切换到另一个线程执行，这个切换不仅增加了成本，而且毫无意义。

还不如只创建两个线程，每个线程只处理一组fds中的一半，处理完一个请求，再去处理另一个请求。不过如果是在用户态是做不了这件事的，只有调度器去搞定。这样你就只能等待在多个fd上，哪个fd请求，就去处理哪一个，处理完再去看看有没有下一个fd需要请求。

然而，如果随着fd的数量的不断增加，效率就会变得越来越低。

总之，对于select，应该没有什么好办法了，应该只能做到这样了，如果你觉得可能某一天，select实现了更高效的算法呢？

我觉得应该不会的，select接口已经那样了。我们只能接受select这个接口的缺陷，明明知道会带来限制，我们就知道去规避这个缺陷，知道什么情况下使用它。

再来看看epoll接口：

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)

从接口看，和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设计的并不好，像是个补丁，功能太专一，只是简单粗暴的增加了一个内核调用，没有从整个架构上考虑，所以内核开发者重新考量了epoll开发出来之前真正的需求是什么，后面就意识到其实真正的需求是一种内核态到用户态之间的事件通知机制，后面就给出了一个解决方案，用户程序不但可以监听网络请求时间，还可以监听像文件修改等各种内核事件，后面这个方案也被3大BSD和苹果的 Mac OSX 内核所采用。

当我们分析epoll和select的时候，我们不能直接跳跃到内核看是怎么实现的，应该看它的整个逻辑来分析，脑子里要形成一些疑问，就比如select已经存在的缺陷是什么？但是又有什么好处？epoll为什么改进？改进了是不更好了？还有没有值得优化的地方？通过整个分析理解下来就能更加了解epoll和select。

分享是一种积极的生活态度