epoll

生活中的例子：区分select和epoll

以一个生活中的例子来解释.
假设你在大学中读书,要等待一个朋友来访,而这个朋友只知道你在A号楼,但是不知道你具体住在哪里,于是你们约好了在A号楼门口见面.
如果你使用的阻塞IO模型来处理这个问题,那么你就只能一直守候在A号楼门口等待朋友的到来,在这段时间里你不能做别的事情,不难知道,这种方式的效率是低下的.
进一步解释select和epoll模型的差异.
select版大妈做的是如下的事情:比如同学甲的朋友来了,select版大妈比较笨,她带着朋友挨个房间进行查询谁是同学甲,你等的朋友来了,于是在实际的代码中,select版大妈做的是以下的事情:
int n = select(&readset,NULL,NULL,100); for (int i = 0; n > 0; ++i) { if (FD_ISSET(fdarray[i], &readset)) { do_something(fdarray[i]); --n; } }epoll版大妈就比较先进了,她记下了同学甲的信息,比如说他的房间号,那么等同学甲的朋友到来时,只需要告诉该朋友同学甲在哪个房间即可,不用自己亲自带着人满大楼的找人了.于是epoll版大妈做的事情可以用如下的代码表示:
n = epoll_wait(epfd,events,20,500); for(i=0;i<n;++i) { do_something(events[n]); } 在epoll中,关键的数据结构epoll_event定义如下:
typedef union epoll_data { void *ptr; int fd; __uint32_t u32; __uint64_t u64; } epoll_data_t; struct epoll_event { __uint32_t events; /* Epoll events */ epoll_data_t data; /* User data variable */ }; 可以看到,epoll_data是一个union结构体,它就是epoll版大妈用于保存同学信息的结构体,它可以保存很多类型的信息:fd,指针,等等.有了这个结构体,epoll大妈可以不用吹灰之力就可以定位到同学甲.
别小看了这些效率的提高,在一个大规模并发的服务器中,轮询IO是最耗时间的操作之一.再回到那个例子中,如果每到来一个朋友楼管大妈都要全楼的查询同学,那么处理的效率必然就低下了,过不久楼底就有不少的人了.

我们用起epoll来都感觉挺爽，确实快，那么，它到底为什么可以高速处理这么多并发连接呢？ 先简单回顾下如何使用C库封装的3个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); 使用起来很清晰，首先要调用epoll_create建立一个epoll对象。参数size是内核保证能够正确处理的最大句柄数，多于这个最大数时内核可不保证效果。
epoll_ctl可以操作上面建立的epoll，例如，将刚建立的socket加入到epoll中让其监控，或者把 epoll正在监控的某个socket句柄移出epoll，不再监控它等等。
epoll_wait在调用时，在给定的timeout时间内，当在监控的所有句柄中有事件发生时，就返回用户态的进程。
从上面的调用方式就可以看到epoll比select/poll的优越之处：因为后者每次调用时都要传递你所要监控的所有socket给select/poll系统调用，这意味着需要将用户态的socket列表copy到内核态，如果以万计的句柄会导致每次都要copy几十几百KB的内存到内核态，非常低效。而我们调用epoll_wait时就相当于以往调用select/poll，但是这时却不用传递socket句柄给内核，因为内核已经在epoll_ctl中拿到了要监控的句柄列表。
所以，实际上在你调用epoll_create后，内核就已经在内核态开始准备帮你存储要监控的句柄了，每次调用epoll_ctl只是在往内核的数据结构里塞入新的socket句柄，当我们调用epoll_ctl往里塞入百万个句柄时，epoll_wait仍然可以飞快的返回，并有效的将发生事件的句柄给我们用户。这是由于我们在调用epoll_create时，内核除了帮我们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket外，还会再建立一个list链表，用于存储准备就绪的事件，当epoll_wait调用时，仅仅观察这个list链表里有没有数据即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。所以，epoll_wait非常高效。

一颗红黑树，一张准备就绪句柄链表，少量的内核cache，就帮我们解决了大并发下的socket处理问题。执行epoll_create时，创建了红黑树和就绪链表，执行epoll_ctl时，如果增加socket句柄，则检查在红黑树中是否存在，存在立即返回，不存在则添加到树干上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据。执行epoll_wait时立刻返回准备就绪链表里的数据即可。
最后看看epoll独有的两种模式LT和ET。无论是LT和ET模式，都适用于以上所说的流程。区别是，LT模式下，只要一个句柄上的事件一次没有处理完，会在以后调用epoll_wait时次次返回这个句柄，而ET模式仅在第一次返回。

epoll和kqueue的比较

性能

从性能角度讲，epoll存在一个设计上的缺陷；它不能在单次系统调用中多次更新兴趣集。当你的兴趣集中有100个文件描述符需要更新状态时，你不得不调用100次epoll_ctl()函数。性能降级在过渡的系统调用时表现的非常明显，这篇文章有做解释。我猜这是Banga et al原来工作的遗留，正如declare_interest()只支持一次调用一次更新那样。相对的，你可以在一次的kevent调用中指定进行多次兴趣集更新。

非文件类型支持

另一个问题，在我看了更重要一些，同样也是epoll的一个限制。它的设计目的是为了提高select()/poll()的性能，epoll只能基 于文件描述符工作。这有什么问题吗？ 一个常见的说法是“在unix中，所有东西都是文件”。大部分情况都是对的，但并不总是这样。例如时钟就不是，信号也不是，信号量也不是，包括进程也不 是。(在Linux中)网络设备也不是文件。在类Unix系统中有好多事物都不是文件。你无法对这些事物采用select()/poll() /epoll()的事件复用技术。典型的网络服务器管理很多类型的资源，除了套接字外。你可能想通过一个单一的接口来管理它们，但是你做不到。为了避免这 个问题，Linux提供了很多补充性质的系统调用，如signalfd()，eventfd()和timerfd_create()来转换非文件类型到文 件描述符，这样你就可以使用epoll了。但是看起来不那么的优雅...你真的想让用一个单独的系统调用来处理每一种资源类型吗？ 在kqueue中，多才多艺的kevent结构体支持多种非文件事件。例如，你的程序可以获得一个子进程退出事件通知(通过设置filter = EVFILT_PROC, ident = pid, 和fflags = NOTE_EXIT)。即便有些资源或事件不被当前版本的内核支持，它们也会在将来的内核中被支持，同时还不用修改任何API接口。

磁盘文件支持

最后一个问题是epoll并不支持所有的文件描述符；select()/poll()/epoll()不能工作在常规的磁盘文件上。这是因为 epoll有一个强烈基于准备就绪模型的假设前提。你监视的是准备就绪的套接字，因此套接字上的顺序IO调用不会发生阻塞。但是磁盘文件并不符合这种模 型，因为它们总是处于就绪状态。 磁盘I/O只有在数据没有被缓存到内存时会发生阻塞，而不是因为客户端没发送消息。磁盘文件的模型是完成通知模型。在这样的模型里，你只是产生I/O操 纵，然后等待完成通知。kqueue支持这种方式，通过设置EVFILT_AIO 过滤器类型来关联到 POSIX AIO功能上，诸如aio_read()。在Linux中，你只能祈祷因为缓存命中率高而磁盘发生不阻塞(这种情况在通常的网络服务器上是个彩蛋)，或者 通过分离线程来使得磁盘I/O阻塞不会影响网络套接字的处理(如FLASH架构)。

简单但不严谨的说：

• 当调用epoll_ctl时，epoll就向底层（poll()，或tcp_poll()）注册了callback
  
• 当文件描述符就绪时，callback函数就会被调用，callback函数就会把该文件描述符加入列表并唤醒epoll_wait
  
• 当调用epoll_wait时，epoll只是简单地检查下列表是否为空，不为空就返回，为空就挂起，等待被唤醒。
  

通常来说select和poll属于I/O multiplexing，而epoll可以算作signal driven I/O

什么是epoll

epoll是什么？按照man手册的说法：是为处理大批量句柄而作了改进的poll。当然，这不是2.6内核才有的，它是在2.5.44内核中被引进的(epoll(4) is a new API introduced in Linux kernel 2.5.44)，它几乎具备了之前所说的一切优点，被公认为Linux2.6下性能最好的多路I/O就绪通知方法。

 

epoll的相关系统调用

epoll只有epoll_create,epoll_ctl,epoll_wait 3个系统调用。

 

1. int epoll_create(int size);

创建一个epoll的句柄。自从linux2.6.8之后，size参数是被忽略的。需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。

 

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll的事件注册函数，它不同于select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。

第一个参数是epoll_create()的返回值。

第二个参数表示动作，用三个宏来表示：

EPOLL_CTL_ADD：注册新的fd到epfd中；

EPOLL_CTL_MOD：修改已经注册的fd的监听事件；

EPOLL_CTL_DEL：从epfd中删除一个fd；

 

第三个参数是需要监听的fd。

第四个参数是告诉内核需要监听什么事，struct epoll_event结构如下：

[cpp]   view plain   copy print ?

1. //保存触发事件的某个文件描述符相关的数据（与具体使用方式有关）  
2.   
3. typedef union epoll_data {  
4.     void *ptr;  (可以用于指针回调)
5.     int fd;  
6.     __uint32_t u32;  
7.     __uint64_t u64;  
8. } epoll_data_t;  
9.  //感兴趣的事件和被触发的事件  
10. struct epoll_event {  
11.     __uint32_t events; /* Epoll events */  
12.     epoll_data_t data; /* User data variable */  
13. };  

events可以是以下几个宏的集合：

EPOLLIN ：表示对应的文件描述符可以读（包括对端