epoll源码剖析后对其总结以理解

阅读完源码的收获 

1. 阅读epoll源码对我的源码阅读能力有所提高
2. 通过对源码的阅读我对内核的有了初步的认识
3. 对epoll的底层有更深入的了解，也知道了epoll的大体流程
    
   当有大量的fd就绪的时候，select和poll的效率要比epoll稍微高一点点（也可能差不多）
   原因：epoll底层使用红黑树，当有fd就绪时对红黑树插入时，可能需要红黑树的结构发生调整变化，比如旋转变色操作。并且回调函数把fd放入rdllist列表里，epoll_wait函数还要在rdllist队列不停的寻找 是否有就绪事件。但select和poll只需要把大量的fd从用户态拷贝到内核态，内核态对其进行遍历一边找到就绪的fd就好了。
    
   Select缺点：

1. 每次调用select都需要把fd从用户态拷贝到内科态，这个开销在fd很多时就会很大。
2. 文件描述符就绪时，内核会修改readfds，writefds，execptfds结构，所以每次调用select之前，必须要重新将文件描述符注册一遍。
3. 每次调用select都需要将传进来的文件描述符重回新遍历一遍，这个开销在fd很多时也很大。
4. 单个进程能够监听到文件描述符存在最大限制。
    
   Poll优点

1. 将用户关注的文件描述符的事件单独表示，可关注更多的事件类型；
2. 将用户传进来的和内核修改的分开，每次调用poll之前，不需要重新设置。
3. Poll函数没有最大文件描述符的限制。
   Poll的缺点：
   A.每次调用都要将用户空间数组拷贝到内核空间；
   B.每次返回都需要将所有的文件描述符拷贝到用户空间数组中，无论是否就绪；
   C.返回的是所有的文件描述符，搜索就绪文件描述符的时间复杂度为o（n）；
    
   Epoll优点：

1. 仅从上面的调用方式就可以看出epoll比select/poll的一个优势：select/poll 每次调用都要传递所要监控的所有