既然 Epoll 相比 select 这么好，那么用起来如何呢？会不会很繁琐啊 … 先看看下面的三个函数吧，就知道 Epoll 的易用了。
int epoll_create(int size);
生成一个 Epoll 专用的文件描述符，其实是申请一个内核空间，用来存放你想关注的 socket fd 上是否发生以及发生了什么事件。 size 就是你在这个 Epoll fd 上能关注的最大 socket fd 数，大小自定，只要内存足够。
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event );
控制某个 Epoll 文件描述符上的事件：注册、修改、删除。其中参数 epfd 是 epoll_create() 创建 Epoll 专用的文件描述符。相对于 select 模型中的 FD_SET 和 FD_CLR 宏。
int epoll_wait(int epfd,struct epoll_event * events,int maxevents,int timeout);
等待 I/O 事件的发生；参数说明：
epfd: 由 epoll_create() 生成的 Epoll 专用的文件描述符；
epoll_event: 用于回传代处理事件的数组；
maxevents: 每次能处理的事件数；
timeout: 等待 I/O 事件发生的超时值；
返回发生事件数。
相对于 select 模型中的 select 函数。
7. epoll的两种工作模式LT/ET
EPOLLLT
完全靠kernel epoll驱动，应用程序只需要处理从epoll_wait返回的fds，应用程序可以根据需要，执行读取/写入操作一次或多次
此模式下，系统默认所有的fds都是空闲的，只有epoll_wait通知的fds是忙碌的，所以应用系统只需要处理这些fds就可以了
EPOLLET
主要靠应用程序处理fds，应用程序从epoll_wait只能得到哪些fds是由空闲变为忙碌状态。此时应用程序需要自己维护一张fds的表格，把从 epoll_wait获得的状态变化信息登记到这张表格。然后应用程序可以选择遍历这张fds的表格，对处于忙碌状态的fds进行操作。
当读取/写入操作遇到EAGAIN的错误，就表示这个fd由忙碌状态变为空闲状态，在下一次epoll_wait调用之前如果有数据进来或者这个fd的写缓冲区又空闲了，那么epoll_wait会再次通知应用程序，这个fd从空闲状态变为忙碌状态。
此模式下，系统仅仅通知应用程序哪些fds变成了忙碌状态，一旦fd变成忙碌状态，epoll将不再关注这个fd的任何状态信息，直到应用程序通过读写操作触发EAGAIN状态，epoll认为这个fd又变为空闲状态，那么epoll又重新关注这个fd的状态变化。
因此EPOLLET比EPOLLLT对应用程序的要求更多，需要程序员设计的部分也更多，看上去EPOLLLT要简单的多。但是如果这里我们要求对fd有超时控制，EPOLLLT需要有额外的fds遍历操作，而EPOLLET本来就需要不断遍历fds，如此看来使用EPOLLET是更好的选择，EPOLLLT才是设计不够完善的小玩具。
而且由于epoll_wait每次返回的fds的数量有限，在大并发的模式下，EPOLLLT将非常的繁忙，所有的fds都要在它的队列中产生状态消息，而每次只有其中一部分fds被返回给应用程序。
相对于EPOLLET，只要epoll_wait返回一次fds之后，这些fds就从epoll队列中消除，只有应用程序遇到EAGAIN之后fd才会重新添加到epoll队列，如此看来随着epoll_wait的返回，队列中的fds是在减少的，所以在大并发的系统中，EPOLLET更有优势。但是对程序员的要求也更高。