select poll epoll系统架构的实际区别

http://www.ulduzsoft.com/2014/01/select-poll-epoll-practical-difference-for-system-architects/

http://hellojava.info/?p=498&nsukey=27ygi6LOfIPNMj4dgMrLvyefufLcpJnYPG0bo7tUbc7aGlLwLtIjxENVlfHjI1yP93o%2FP8PGySnwOL%2FmDKEiaYnqwUI9UuSK1h%2FRZajI4DXvrhMlgOPMEuLnCucq%2FEjrgEVWGm2330rG0GGNkBiByLqD3FTdivYEU2yXf%2B4940%2Bq%2BjPwEIRESBSACLs0C9JX

下面这篇通俗的解释了select poll epoll的差异

https://blog.csdn.net/z69183787/article/details/52943637

上篇的增强版

http://www.importnew.com/24794.html

上文提到了epoll可以将哪个流发生了什么事件主动通知，而不需要轮询。那么到底是如何实现通知的呢？

这就和操作系统的原理相关，在内核的最底层是中断，类似系统回调的机制。网卡设备对应一个中断号, 当网卡收到网络端的消息的时候会向CPU发起中断请求, 然后CPU处理该请求. 通过驱动程序 进而操作系统得到通知, 系统然后通知epoll, epoll通知用户代码。它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率，因为它会复用文件描述符集合来传递结果而不用迫使开发者每次等待事件之前都必须重新准备要被侦听的文件描述符集合，另一点原因就是获取事件的时候，它无须遍历整个被侦听的描述符集，只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。

epoll在被内核初始化时（操作系统启动），同时会开辟出epoll自己的内核高速cache区，用于安置每一个我们想监控的socket，这些socket会以红黑树的形式保存在内核cache里，以支持快速的查找、插入、删除。这个内核高速cache区，就是建立连续的物理内存页，然后在之上建立slab层，简单的说，就是物理上分配好你想要的size的内存对象，每次使用时都是使用空闲的已分配好的对象。

所以简单总结下epoll和select的区别：

进程通过将一个或多个fd传递给select或poll系统调用，阻塞在select;这样select/poll可以帮我们侦测许多fd是否就绪；但是select/poll是顺序扫描fd是否就绪，而且支持的fd数量有限。linux还提供了一个epoll系统调用，epoll是基于事件驱动方式，而不是顺序扫描,当有fd就绪时，立即回调函数rollback。

关于libevent 与Libev的支持，待解答。