IO复用： select 和poll 到epoll

linux 提供了select、poll和epoll三种接口来实现多路IO复用。下面总结下这三种接口。

select

该函数允许进程指示内核等待多个事件中的任何一个发生，并只在有一个或多个事件发生或经历一段指定的时间后才唤醒它。

函数接口：

   1: #include <sys/select.h>

   2: #include <sys/time.h>

   3:  

   4: int select(int maxfdp1, fd_set *readset, fd_set *writeset, fd_set *exceptset, 

   5:            const struct timeval* timeout);

参数说明：

1. maxfdp1 : 指定待测试的描述符个数，它的值为待测试的最大描述符加1，注意为待测试的最大描述符加1，即从0到maxfdp1均将被测试。
2. readset：  既是输入参数，也是输出参数，输入参数时指明读事件关心的描述符集合，输出参数保存准备好读的描述符集合。
3. writeset:   既是输入参数，也是输出参数，输入参数时指明写事件关心的描述符集合，输出参数保存准备好写的描述符集合。
4. exceptset: 既是输入参数，也是输出参数，输入参数时指明异常条件关心的描述符集合，输出参数保存有异常发生的描述符集合。
5. timeout: 等待的时间， 结构为

      1: struct timeval {

      2:   long tv_set; // 秒

      3:   long tv_usec;  // 微秒 10^-6

      4: }

   
   该参数是一个 相对时间，即距离当前的时间，该参数有三种可能：
   (1) 永远等待下去，仅有在至少一个描述符准备好的IO时才返回，此时该参数值应该为空指针。
   (2) 等待一段时间，在有至少一个描述符准备好IO时返回，或者达到指定的时间，即timeval指定的秒数和微秒数。
   (3) 不等待： 检查描述符后立即返回，成为轮询，此时timeval的值(其中的秒数和微秒数)都必须为0

返回值：

     有就绪的描述符，返回值为就绪的描述符的个数(早期的select如果返回时多个描述符集合的同一位为1，即某个描述符又可读有可写，那么在函数返回值时只计一次，而现在的版本则修正了该问题，按照事件分开计算)，超时返回0， 出错则返回-1.

select的几点说明：

1. select可以关心的描述符有上限限制，通常为1024，该值是由于fd_set集合的大小是由宏FD_SETSIZE限制的，select用户态和内核态交互的fd_set的集合大小就被该参数限制，只有修改该参数，才可以支持更大集合的描述符。而修改该参数就需要重新编译内核。通常可以使用多进程的方式来避免这个问题。(注意是关心的描述符个数限制，而不是maxfdp1)。常见的使用slect的多进程模型是这样的： 一个进程专门accept，成功后将fd通过unix socket传递给子进程处理，父进程可以根据子进程负载分派。比如可以用1个父进程+4个子进程，就可以承载了过4000个的负载。
2. 注意fd_set*类型的三个参数，是同时作为输入参数和输出参数来使用的，即该参数在返回时被修改了，因此，下次调用select的时候需要重新初始化。其值的读取和设置需要使用提供的访问该结构的方法，分别为：
   

      1: void FD_ZERO(fd_set *fdset)   //清空集合

      2: void FD_SET(int fd, fd_set *fdset)  // 设置fdset中fd对应的位

      3: void FD_CLR(int fd, fd_set *fdset)  // 清除fdset中fd对应的位

      4: void FD_ISSET(int fd, fd_set* fdset)  // 检测fdset中fd对应的位是否设置。

3. 个人理解： select的工作方式是对maxfdp1以内的描述符都检测，然后内核逐个检测这些描述符，根据fd_set集合中设置的关心的描述符，将对应描述符的状态设置到fd_set中。返回给用户。而通常尤其在网络IO中，大部分描述符是不活跃的，而当描述符集合增大是，该轮询式的开销是线性增长的，会导致开销越来越大。

poll

poll起源于SVR3， 最初局限于流设备，SVR4取消了这种限制，允许poll工作在任何描述符上。它提供了和select类似的功能。

函数接口：

   1: #include <poll.h>

   2:  

   3: int poll(struct pollfd* fdarray, unsigned long nfds, int timeout);

   4:  

   5: struct pollfd {

   6:   int fd;  // 需要检测的文件描述符

   7:   short event; // fd上关心的事件

   8:   short revent;  // fd上发生的时间，即返回值

   9: };

参数说明：

1. pollfd：该参数是一个结构体，结构体中包含文件描述符，和文件关心的事件，以及用来保存返回事件的revent。该参数既是输入参数又是输出参数。
2. nfds： 该参数指明数组中元素的个数。Unix98 为该参数定义了名为nfds_t的新的数据类型。
3. timeout： poll函数返回前的等待时间，单位是毫秒数。 可能取值如下：
   
   

   timeout的值	说明
   INFTIM(常被定义为一个负值)	永远等待
   0	立即返回，不阻塞进程
   >0	等待指定数目的毫秒数

返回值：

    发生错误的时候，返回-1， 定时器到时之前没有任何描述符就绪，返回0. 否则返回就绪描述符的个数，即revents成员非0的描述符个数。

poll函数的几点说明：

1. poll使用单独的参数nfds表示关心的描述符的个数，因此不再有select的数量限制，分配一个pollfd结构的数组并把该数组中元素的数目通知内核成了调用者的责任，内核不再需要知道类似fd_set的固定大小的数据类型。
2. pollfd中关心的事件和返回的事件分别由events和revents两个参数表示。因此不再需要每次都重新设置。而如果我们不再关心某个描述符，可以把与它对应的pollfd结构中的fd成员设置成一个负值。poll函数将忽略这样的pollfd结构的events成员，返回时将它的revents成员的值置为0。
3. poll每次都会对数组中的描述符全部轮询的检测一遍，这点还是和select类似的。因此还存在当描述符数量较大时的开销问题。

poll的原理：

poll是一个系统调用，其内核入口函数为sys_poll，sys_poll几乎不做任何处理直接调用do_sys_poll，do_sys_poll的执行过程可以分为三个部分：
       1，将用户传入的pollfd数组拷贝到内核空间，因为拷贝操作和数组长度相关，时间上这是一个O（n）操作，这一步的代码在do_sys_poll中包括从函数开始到调用do_poll前的部分。
       2，查询每个文件描述符对应设备的状态，如果该设备尚未就绪，则在该设备的等待队列中加入一项并继续查询下一设备的状态。查询完所有设备后如果没有一个设备就绪，这时则需要挂起当前进程等待，直到设备就绪或者超时，挂起操作是通过调用schedule_timeout执行的。设备就绪后进程被通知继续运行，这时再次遍历所有设备，以查找就绪设备。这一步因为两次遍历所有设备，时间复杂度也是O（n），这里面不包括等待时间。相关代码在do_poll函数中。
       3，将获得的数据传送到用户空间并执行释放内存和剥离等待队列等善后工作，向用户空间拷贝数据与剥离等待队列等操作的的时间复杂度同样是O（n），具体代码包括do_sys_poll函数中调用do_poll后到结束的部分。

epoll

epoll是linux下多路IO复用select/poll的增强版本，它能显著提供程序在大量并发连接中只有少量活跃情况下的系统CPU利用率。

函数结构:

它有三个主要结构，分别为epoll_create，epoll_ctl，epoll_wait。

epoll_create

   1: #include <sys/epoll.h>

   2:  

   3: int epoll_create(int size)

该函数用于创建一个epoll的文件描述符，

参数说明：

    创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大(可以不是监听的总数，该参数用来提示内存分配空间的)。这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值。需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。

返回值：

   成功的返回文件描述符，出错返回-1，并设置errno

  错误类型：

    EINVAL： size不是正数

    ENFILE： 文件描述符达到系统的文件描述符限制

    ENOMEM： 没有足够的内存创建内核对象。

epoll_ctl

   1: #include <sys/epoll.h>

   2:  

   3: int epoll_ctl(int epfd, int op, int fd, struct epoll_event* event);

   4:  

   5: typedef union epoll_data {

   6:   void * ptr;

   7:   int fd;

   8:   _uint32_t u32;

   9:   _uint64_t u64;

  10: }epoll_data_t;

  11:  

  12: struct epoll_event {

  13:   _uint32 events;  // epoll事件

  14:   epoll_data_t data;  // 用户变量。

  15: };

函数说明：

    epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。第一个参数是epoll_create()的返回值，第二个参数表示动作，用三个宏来表示：
EPOLL_CTL_ADD：注册新的fd到epfd中；
EPOLL_CTL_MOD：修改已经注册的fd的监听事件；
EPOLL_CTL_DEL：从epfd中删除一个fd；

   events可以是以下几个宏的集合：
EPOLLIN ：表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；
EPOLLOUT：表示对应的文件描述符可以写；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP：表示对应的文件描述符被挂断；
EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里

返回值：

    成功返回0， 失败返回-1， 并设置errno

   错误类型：

     EBADF： epfd不是一个有效的描述符。

      EEXIST： op为EPOLL_CTL_ADD，并且提供的描述符fd已经在epfd中。此时应该用EPOLL_CTL_MOD

      EINVAL： epfd不是一个epoll文件描述符，或者fd和epfd一样，挥着请求的操作op不是一个有效的操作。

      ENOENT： op是EPOLL_CTL_MOD或者EPOLL_CTL_DEL，并且fd不在epfd中。

     ENOMEM: 没有足够的内存区执行相应的op操作。

     EPERM： epoll不支持目标的文件描述符fd

      

epoll_wait

   1: #include <sys/epoll.h>

   2:  

   3: int epoll_wait(int epfd, struct epoll_event* events, int maxevents, int timeout);

   函数说明：

     epfd是通过epoll_create常见的描述符，events是接受返回事件的结构，maxevents是数组的最大值，timeout是设置超时时间的，单位是毫秒。

    等待事件的产生，类似于select()调用。参数events用来从内核得到事件的集合，maxevents告之内核这个events有多大，这个 maxevents的值必须大于0，maxevents 是epoll_wait可以处理的连接事件的最大限度值，这个值一般要小于或等于epoll_create的那个size，当然如果设置成比size还大 的话也无所谓，size是epoll整体可以监听的最大fd数量。maxevents的意义是防止epoll的API在填写你传进去的指针events的 时候，超过指针指向的内存的大小从而导致内存溢出。参数timeout是超时时间（毫秒，0会立即返回，-1将不确定，也有说法说是永久阻塞）。该函数返回需要处理的事件数目，如返回0表示已超时。

当成功返回时，每个epoll_event结构中将包含epoll_ct中的用户数据。

返回值：

  成功返回准备好的描述符数，超时仍没有描述符准备好返回0， 出错返回-1，并设置errno

  错误类型：

  EBADF： epfd不是一个有效的文件描述符

   EFAULT： 指向events的内存没有写权限

   EINTR： 调用在IO 准备好和超时之前被信号中断

   EINVAL： epfd不是有个epoll文件描述符，或者maxevents小于等于0

 

epoll的几点说明：

1. epoll同样只告知那些就绪的文件描述符，而且当我们调用epoll_wait()获得就绪文件描述符时，返回的不是实际的描述符，而是一个代表就绪描述符数量的值，你只需要去epoll指定的一个数组中依次取得相应数量的文件描述符即可，这里也使用了内存映射（mmap）技术，这样便彻底省掉了这些文件描述符在系统调用时复制的开销。
2. 另一个本质的改进在于epoll采用基于事件的就绪通知方式。在select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便得到通知。

epoll的ET和LT

   ET模式仅当状态发生变化的时候才获得通知(只告诉进程哪些文件描述符刚刚变为就绪状态，),这里所谓的状态的变化并不包括缓冲区中还有未处理的数据,也就是说,如果要采用ET模式,需要一直read/write直到出错为止,很多人反映为什么采用ET模式只接收了一部分数据就再也得不到通知了,大多因为这样;而LT模式是只要有数据没有处理就会一直通知下去的.

 

EPOLL 和poll、select的区别

接下来分析epoll，与poll/select不同，epoll不再是一个单独的系统调用，而是由epoll_create/epoll_ctl/epoll_wait三个系统调用组成，后面将会看到这样做的好处。
       先来看sys_epoll_create(epoll_create对应的内核函数），这个函数主要是做一些准备工作，比如创建数据结构，初始化数据并最终返回一个文件描述符（表示新创建的虚拟epoll文件），这个操作可以认为是一个固定时间的操作。
        epoll是做为一个虚拟文件系统来实现的，这样做至少有以下两个好处：
        1，可以在内核里维护一些信息，这些信息在多次epoll_wait间是保持的，比如所有受监控的文件描述符。
        2， epoll本身也可以被poll/epoll;
       具体epoll的虚拟文件系统的实现和性能分析无关，不再赘述。
       在sys_epoll_create中还能看到一个细节，就是epoll_create的参数size在现阶段是没有意义的，只要大于零就行。
       接着是sys_epoll_ctl(epoll_ctl对应的内核函数），需要明确的是每次调用sys_epoll_ctl只处理一个文件描述符，这里主要描述当op为EPOLL_CTL_ADD时的执行过程，sys_epoll_ctl做一些安全性检查后进入ep_insert，ep_insert里将 ep_poll_callback做为回掉函数加入设备的等待队列（假定这时设备尚未就绪），由于每次poll_ctl只操作一个文件描述符，因此也可以认为这是一个O(1)操作
        ep_poll_callback函数很关键，它在所等待的设备就绪后被系统回掉，执行两个操作：
       1，将就绪设备加入就绪队列，这一步避免了像poll那样在设备就绪后再次轮询所有设备找就绪者，降低了时间复杂度，由O（n）到O（1）;
       2，唤醒虚拟的epoll文件;
       最后是sys_epoll_wait，这里实际执行操作的是ep_poll函数。该函数等待将进程自身插入虚拟epoll文件的等待队列，直到被唤醒（见上面ep_poll_callback函数描述），最后执行ep_events_transfer将结果拷贝到用户空间。由于只拷贝就绪设备信息，所以这里的拷贝是一个O(1）操作。
       还有一个让人关心的问题就是epoll对EPOLLET的处理，即边沿触发的处理，粗略看代码就是把一部分水平触发模式下内核做的工作交给用户来处理，直觉上不会对性能有太大影响，感兴趣的朋友欢迎讨论。
POLL/EPOLL对比：
       表面上poll的过程可以看作是由一次epoll_create/若干次epoll_ctl/一次epoll_wait/一次close等系统调用构成，实际上epoll将poll分成若干部分实现的原因正是因为服务器软件中使用poll的特点（比如Web服务器）：
       1，需要同时poll大量文件描述符;
       2，每次poll完成后就绪的文件描述符只占所有被poll的描述符的很少一部分。
       3，前后多次poll调用对文件描述符数组（ufds）的修改只是很小;
       传统的poll函数相当于每次调用都重起炉灶，从用户空间完整读入ufds，完成后再次完全拷贝到用户空间，另外每次poll都需要对所有设备做至少做一次加入和删除等待队列操作，这些都是低效的原因。
        epoll将以上情况都细化考虑，不需要每次都完整读入输出ufds，只需使用epoll_ctl调整其中一小部分，不需要每次epoll_wait都执行一次加入删除等待队列操作，另外改进后的机制使的不必在某个设备就绪后搜索整个设备数组进行查找，这些都能提高效率。另外最明显的一点，从用户的使用来说，使用epoll不必每次都轮询所有返回结果已找出其中的就绪部分，O（n）变O（1），对性能也提高不少。
       此外这里还发现一点，是不是将epoll_ctl改成一次可以处理多个fd（像semctl那样）会提高些许性能呢？特别是在假设系统调用比较耗时的基础上。不过关于系统调用的耗时问题还会在以后分析。

总结

     epoll由于实现相对复杂，其适合有较多描述符，并且其中较大多数处于非活跃的场景。我们在使用中应该结合自己的场景选择合适的IO多路复用模型。而不能一概的认为epoll就是最有的选择。

refer：http://kaiyuan.blog.51cto.com/930309/341121

         http://www.360doc.com/content/09/0727/15/1894_4486873.shtml

         http://blog.csdn.net/ljx0305/article/details/4065058

         http://blog.endlesscode.com/2010/03/27/select-poll-epoll-intro/