epoll机制

使用 epoll，你创建一个唯一的fd，整合事件和多个你想监控的文件描述符（存在于 open file description），因此监控列表是持久的 或者说 长期的，通过多个系统调用后，线程继续停留在fd等待队列上。而且，epfd可以在多个线程间共享，在fd等待队列中不再只有一个线程，而是一个数据结 构，包含当前正在epfd上等待的所有线程。（根据Linux实现，socket fd等待队列持有一个函数指针，一个 void *数据指针传递给那个函数；感觉这个地方特别别扭，如果不纠结于实现的话，可以任务epfd 和 socket fd之间会有一种关联关系）。

so，详细解释这种机制：

1、epoll fd有一个私有的struct eventpoll，它记录哪一个fd注册到了epfd上。eventpoll 同样有一个等待队列，记录所有等待的线程。还有一个预备好的fd列表，这些fd可以进行读或写。    

2、使用 epoll_ctl 添加fd到epfd，epoll 添加 eventpoll 到 fd的等待队列（指针 or something？）。同时检查这个fd是否是ready状态（可读，可写），如果ready，添加到 ready list。

3、线程调用 epoll_wait 等待时，内核首先检查ready list，如果有fd ready，立即返回。如果没有 ready list，添加到 epfd 的等待队列中，开始休眠。

4、当 epfd 监控的socket有事件发生时，添加 fd 到 ready list，唤醒等待 epfd 的所有线程。

明显的，struct eventpoll需要很多小心的锁操作， 多种列表 和 等待队列，但那就是 实现细节了。

要记住的重要的事情是：我上面描述的没有一步是需要遍历兴趣fd列表的。通过完全使用事件驱动，持久的fd集合和兴趣列表，epoll避免消耗 O(n) 时间的操作，n是被监控的文件描述符的个数。

http://my.oschina.net/astute/blog/92683

个人理解：epool机制就是等待消息，如果没有，该线程就休眠，而不会让线程堵死，当notify时，会叫醒该线程。让该线程干活

 

 Poll就是监控文件是否可读的一种机制，作用与select一样。
应用程序的调用函数如下：
int poll(struct pollfd *fds,nfds_t nfds, int timeout);
Poll机制会判断fds中的文件是否可读，如果可读则会立即返回，返回的值就是可读fd的数量，如果不可读，那么就等待
一定的时间timeout, 超时则返回。