select:http://www.cnblogs.com/Anker/archive/2013/08/14/3258674.html
poll : http://www.cnblogs.com/Anker/archive/2013/08/15/3261006.html
epoll:http://www.cnblogs.com/Anker/archive/2013/08/17/3263780.html
假设telnet进程有两个输入,两个输出。我们不能对两个输入中的任一个使用阻塞read,因为我们不知道到底哪一个输入会得到数据。一个方法是使用一个进程去执行该程序,但是用非阻塞IO读取数据。基本思想是:将两个输入描述符都设置为非阻塞的,对第一个描述符发一个read。如果该输入上有数据,则读数据并处理它。如果该输入上没有数据,则调用会立即返回。然后对第二个描述符进行同样的处理。在此之后,等待一段时间(可能是若干秒),然后再尝试从第一个描述符读。这种形式的循环成为轮询。这种方法的不足之处在于浪费了CPU时间。大多数时间实际上是无数据可读,因此执行read系统调用浪费了时间。 一种较好的技术是使用IO多路转接(IO Multiplexing)。为了使用这种技术,先构造一张我们感兴趣的描述符的列表,然后调用一个函数,直到这些描述符中一个已经准备好进行IO时,该函数才会返回。select函数使我们可以执行IO多路转接。
select的缺点:
1. 单个进程能够监视的文件描述符的数量存在最大限制,通常是1024,但由于select采用轮询的方式扫描文件描述符,文件描述符的数量越多,性能越差;
2. 内核/用户空间内存拷贝问题,select需要复制大量的句柄数据结构,产生巨大的开销
3. select返回的是含所有整个句柄的数组,应用程序需要遍历整个数组才能发现那些句柄发生了事件;
4. select的触发方式是水平触发,如果应用程序没有完成对一个已经就绪的文件描述符进行IO操作,那么之后每次select调用的还是会将这些文件描述符通知进程。
相比于select模型,poll使用链表来保存文件描述符,因此没有了监视文件数量的限制。但是其他的三个缺点仍然存在。
epoll的设计与实现与select完全不同。epoll通过在linux内核中申请一个简易的文件系统。把原先的select/poll调用分成了3个部分:
1.调用epoll_create()建立一个epoll对象
2. 调用epoll_ctl向epoll对象中添加,删除、修改感兴趣的事件
3. 调用epoll_wait, 通过此调用手机在epoll监控中已经发生的事件。
如此一来,要实现上面说的场景,只需要在进程启动时建立一个epoll对象, 然后在需要的时候向epoll这个对象添加或者是删除连接。同时epoll_wait效率也非常高,内核并不需要建立去哪不得连接,也不需要向操作系统复制全部的句柄数据。
struct eventpoll{
....
/*红黑树的根节点,这颗树中存储着所有添加到epoll中的需要监控的事件*/
struct rb_root rbr;
/*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/
struct list_head rdlist;
....
};
每一个epoll对象都有一个独立的eventpoll结构体,用于存放epoll_ctl方法向epoll对象中添加进来的事件。这些时间都会挂载在红黑树中,如此,重复添加的事件就可以通过红黑树而高效的识别出来。
而所有添加到epoll中的时间都会与设备驱动程序建立回调关系,也就是说,当相应的时间发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。在epoll中,对于每一个事件,都会建立一个epitem结构体。
struct epitem{
struct rb_node rbn;//红黑树节点
struct list_head rdllink;//双向链表节点
struct epoll_filefd ffd; //事件句柄信息
struct eventpoll *ep; //指向其所属的eventpoll对象
struct epoll_event event; //期待发生的事件类型
}
当调用epoll_wait检查是否有事件发生时,只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可,如果rdlist不为空,则把发生的事件复制到用户态,同时将事件数量返回给用户。
通过红黑树和双链表的数据结构,并结合回调机制,造就了epoll的高效。