Nicholas Ding

select(), poll() 的局限性

• 传统方式的 select() 系统调用受到 FD_SETSIZE 大小的限制。这个限制被编译进了标准库，虽然某些C函数库允许你在编译的时候增加这个限额，但毕竟不是一个通用的方法。
• 传统的 poll() 系统调用虽然没有 select() 的 FD_SETSIZE 大小的限制，但是在处理上千个连接的时候会变的越来越慢，虽然那时侯大部分的fd都是闲置的，但是一便便的扫描fd的状态非常耗时。

kqueue() 和 epoll()

• kqueue() 是 FreeBSD 下推荐的支持 edge-triggered 方式的 poll 模式的替代品。
• epoll 则是在 Linux kernel 2.6 的时候正式加入进来的，同样是推荐的 edge-triggered 的 poll 模式的替代品。

select(), poll() 与 kqueue(), epoll() 实现上的细微差别

• 为什么 select() 和 poll() 系统调用在性能上会有问题，就和之前提到的一样，系统总是需要一次次的扫描file descriptors列表来标记那些改变的部分，然后客户端应用再次扫描这个列表取出fd进行操作，在服务器负载很高的情况下，维护的fd列表相当长，扫描的时间非常长，同时也让CPU负荷很高。
• kqueue() 和 epoll() 则是让 kernel 主动通知应用程序关于fd的修改，这样就免去了这些扫描的过程，当然内部的实现应该比这个复杂的多。