select/poll/epoll 对比

首先还是来看常见的select和poll。对于网络编程来说，一般认为poll比select要高级一些，这主要源于以下几个原因：

1. poll() 不要求开发者计算最大文件描述符加一的大小。
2. poll() 在应付大数目的文件描述符的时候速度更快，因为对于select()来说内核需要检查大量描述符对应的fd_set 中的每一个比特位，比较费时。
3. select 可以监控的文件描述符数目是固定的，相对来说也较少（1024或2048），如果需要监控数值比较大的文件描述符，就算所监控的描述符很少，如果分布的很稀疏也会效率很低，对于poll() 函数来说，就可以创建特定大小的数组来保存监控的描述符，而不受文件描述符值大小的影响，而且poll()可以监控的文件数目远大于select。
4. 对于select来说，所监控的fd_set在select返回之后会发生变化，所以在下一次进入select()之前都需要重新初始化需要监控的fd_set，poll() 函数将监控的输入和输出事件分开，允许被监控的文件数组被复用而不需要重新初始化。
5. select() 函数的超时参数在返回时也是未定义的，考虑到可移植性，每次在超时之后在下一次进入到select之前都需要重新设置超时参数。

　　当然也不是说select就没有优点：

1. select()的可移植性更好，在某些Unix系统上不支持poll()
2. select() 对于超时值提供了更好的精度：微秒，而poll是毫秒。

epoll的优点：

1.支持一个进程打开大数目的socket描述符(FD)

　　select 最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置，默认值是1024/2048。对于那些需要支持的上万连接数目的IM服务器来说显然太少了。这时候你一是可以选择修改这个宏然后重新编译内核。不过 epoll则没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

2.IO效率不随FD数目增加而线性下降

　　传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是"活跃"的，但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对"活跃"的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个"伪"AIO，因为这时候推动力在Linux内核。

3.使用mmap加速内核与用户空间的消息传递。

　　这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核与用户空间mmap同一块内存实现的。 

　　对于poll来说需要将用户传入的 pollfd 数组拷贝到内核空间，因为拷贝操作和数组长度相关，时间上这是一个O（n）操作，当事件发生，poll返回将获得的数据传送到用户空间并执行释放内存和剥离等待队列等善后工作，向用户空间拷贝数据与剥离等待队列等操作的的时间复杂度同样是O（n）。

　　这两天看到一个云风他们那里的bug就是因为使用的开源库中作者使用了非阻塞connect使用select() 来等待超时，但是并未检查FD_SETSIZE，当文件描述符数目大于这个数目之后就会出现内存越界错误，造成coredump。