epoll原理
1、 epoll 与 poll/select
epoll是由一组系统调用组成。
int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout);
select/poll的缺点在于：
1.每次调用时要重复地从用户态读入参数。
2.每次调用时要重复地扫描文件描述符。
3.每次在调用开始时，要把当前进程放入各个文件描述符的等待队列。在调用结束后，又把进程从各个等待队列中删除。
在实际应用中，select/poll监视的文件描述符可能会非常多，如果每次只是返回一小部分，那么，这种情况下select/poll
显得不够高效。epoll的设计思路，是把select/poll单个的操作拆分为1个epoll_create+多个epoll_ctrl+一个epoll_wait。
=========每次select时的参数都需要拷贝到内核态； 返回时从内核态删除。
=========epoll_wait无参； 在epoll_ctrl中就已经拷贝到内核态、且仅拷贝一次。
2、epoll本身特点
0）epoll_wait/epoll_ctl是多线程安全的。底层的红黑树由mutex保护，ready list由spinlock保护。
1）一个fd上多个事件触发时， 是combination到一起返回的。 所以：
----if(which &EPOLLIN) dosomething;
----else if(which &EPOLLOUT) dosomething； 这种方式不太合适、可能漏掉通知。(客户端是应答式的就没问题了)
2）close就会将fd从epoll_set中移除
3）可以多线程同时进行epoll事件分发处理。 |EPOLLONESHOT、epoll_wait返回之后需要epoll_ctl(MOD)恢复
3、epoll的ET与LT
ET更快， 因为ET减少了epoll_wait的系统调用次数。
ET缺省是ready状态； 直到EAGAIN。 只能用户nonblock
==========对于data socket, 应该是开始只注册读、 读完后处理数据只注册写、写完后只注册读这个过程重复【半双工】？ 如果数据处理的逻辑很耗时，后面需要线程池来处理？ 一个线程在epoll_wait的过程当中， 另外一个线程能epoll_ctl吗？
==========还是同时注册读写， 让epoll_wait频繁的醒来？
LT缺省是readiness状态。可用于block或者nonblock
4、问题与建议
1） 饥饿？ 不止是epoll的问题， 也不是epoll的问题； 任何io分发器都会有这样的问题。应该由应用来解决。
2） event cache... ........ from "man epoll"
=====================================================================================
当epoll后面的数据处理逻辑比较慢时， 比如磁盘io？， 有两种方式提高性能：
1） epoll读到完整消息后， 将消息给worker线程处理
2）多线程epoll_wait+ONESHOT。
结论， 经过上述综合， 使用多线程+ONESHOT可能较好。
至于是LT还是ET？ 如果不考虑饥饿的话， ET比较高效； 如果需要考虑饥饿的话呢
参考：
http://www.cnblogs.com/dkblog/archive/2010/12/08/1980680.html
http://blog.chinaunix.net/uid-20937170-id-4206879.html
http://bbs.csdn.net/topics/390370165