I/O多路复用之EPOLL

发表于 3年以前 | 总阅读数：329 次

epoll是一种事件轮询，是Linux特有的。它允许一个进程监视多个文件描述符，并在对它们进行I/O操作时获取通知。它允许边缘触发和级别触发通知。在我们研究epoll的内部之前，首先让我们研究一下语法。

1 语义

与poll不同，epoll本身不是系统调用。它是一种内核数据结构，允许进程在多个文件描述符上复用I/O。

这个数据结构可以通过三个系统调用来创建、修改和删除。

1、epoll_create

通过系统调用epoll_create，可以创建一个epoll实例，该系统调用返回一个指向epoll实例的文件描述符。函数调用如下：

#include <sys/epoll.h>
int epoll_create(int size);

size参数向内核指定内核进程需要监控的文件描述符的个数，这有助于内核决定epoll实例的大小。从Linux2.6.8开始，这个参数就被忽略了，因为epoll数据结构会随着文件描述符的添加或删除而动态调整大小。

进程通过调用epoll_create来创建epoll实例，后续通过epoll返回的指向epoll实例的文件描述符来进行各种操作，比如添加、删除或者修改它想要件事epoll实例的I/O的其他文件描述符。

在Linux系统中，还有另外一个系统调用函数epoll_create1，其声明如下：

int epoll_create1(int flags);

其中，flags参数可以是0或EPOLL_CLOEXEC。当flggs为0时候，epoll_create1(0)与epoll_create功能一致。如果设置为EPOLL_CLOEXEC，那么由当前进程fork出来的任何子进程，其都会关闭其父进程的epoll实例所指向的文件描述符，也就是说子进程没有访问父进程epoll实例的权限。需要注意的是，与epoll实例关联的文件描述符需要通过close()系统调用来释放。多个进程可能持有同一epoll实例的描述符。这是因为，假如没有设置EPOLL_CLOEXEC标志的fork将把描述符复制到子进程中的epoll实例,当这些进程中的某一个或者多个进程关闭了其中一个文件描述符，那么可能会导致程序的不可用，或者不在我们的预期之内。

2、epoll_ctl

进程可以通过调用epoll_ctl将它想要监视的文件描述符添加到epoll实例中。所有注册到epoll实例的文件描述符统称为epoll集或目前监控列表。

在上图中，进程483已向epoll实例注册了文件描述符fd1、fd2、fd3、fd4和fd5。这是该特定EPOL实例的目标监控列表或EPOL集。随后，当注册的任何文件描述符有I/O事件时候，该描述符将被放入就绪列表中。其中，就绪列表是目标监控列表的子集。

epoll_ctl函数的声明如下:

#include <sys/epoll.h>
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

参数含义如下:

epfd: epoll_create函数返回的文件描述符，用于标识内核中的epoll实例。 fd:需要被操作的文件描述符 op:对fd文件描述符的操作类型。主要有如下几个
- EPOLL_CTL_ADD 向epfd实例进行注册，在有I/O事件时候获得通知
- EPOLL_CTL_DEL 从EPOL实例中删除/注销fd。这意味着进程将不再收到关于该文件描述符上事件的任何通知    （EPOLL_CTL_DEL ）。如果文件描述符已添加到多个EPOL实例中，则关闭它将从添加到该实例的所有EPOL目标监控列表中删除它。
- EPOLL_CTL_MOD 修改正在监视的fd事件
event: 一个指向一个名为epoll_event的结构的指针，它存储了我们实际要监视fd的事件。

ev描述如下图

epoll_event事件结构的第一个字段事件是一个位掩码，它指示要监视哪个事件fd。

与此类似，如果fd是套接字，我们可能希望监视它是否在套接字缓冲区（epolin）上到达新数据。我们还可能希望监视fd，以了解由EPOLET或使用EPOLIN生成的边缘触发通知。我们还可能希望监视fd是否发生注册事件，但仅监视一次fd，并停止监视fd以了解该事件的后续事件。这可以通过或通过设置其他标志（EPOLLET、EPOLLIN）来实现，我们希望为描述符fd设置标记，仅用于一次通知传递epoloneshot。所有可能的标志都可以在手册页中找到。

epoll_event事件结构的第二个字段是一个联合字段。

3、epoll_wait

epoll_wait系统调用，用来监视epoll set/interest集上发生的事件。如果被监视的epoll set/interest集上没有任何I/O事件，则该调用会一直被阻塞，直至有I/O事件产生。该函数声明如下:

#include <sys/epoll.h>
int epoll_wait(int epfd, struct epoll_event *evlist, int maxevents, int timeout);

参数含义如下:

epfd: epoll_create函数返回的文件描述符，用于标识内核中的epoll实例。 evlist: epoll事件结构的数组。evlist由调用进程分配，当epoll_wait返回时，修改此数组以指示有关目标监控列表中处于就绪状态的文件描述符子集的信息（这称为就绪列表） maxevents : evlist数组大小 timeout：此参数的意思与poll或select相同。此值指定epoll_wait系统调用的阻塞时间：

当设置为0时，代表该函数不会被阻塞，其在检查完目标监控列表中有无I/O事件之后，马上就返回。

当设置为-1时候，该函数将被永久阻塞，进程将处于休眠状态，直到满足下面两个条件(1) 有I/O事件发生 (2) 被信号处理程序中断。

当设置为非负值和非零值时，epoll_wait将阻塞，直到满足有如下几个条件之一(1) 在epfd的目标监控列表中指定的一个或多个描述符就绪，(2) 调用被信号处理程序中断 (3) timeout毫秒指定的时间量已过期

epoll_wait 函数的返回值有以下几种:

-如果发生错误（EBADF或EINTR或EFAULT或EINVAL），则返回代码为-1 如果调用在目标监控列表中的任何文件描述符就绪之前超时，则返回代码为0。如果目标监控列表中的一个或多个文件描述符准备就绪，则返回代码为正整数，表示evlist数组中的文件描述符总数。然后检查evlist以确定哪些事件发生在哪些文件描述符上。

2 深入

要完全理解epoll背后的细微差别，理解文件描述符是如何工作的是很重要的。进程通过文件描述符与I/O流进行关联，每个进程都维护一个它可以访问的文件描述符表。该表有两个字段：

控制文件描述符操作的标志（唯一的标志是exec关闭标志）
指向基础内核数据结构的指针文件描述符可以通过系统调用（例如open，pipe，socket等）显式创建，也可以在派生期间从父进程继承。描述符也与dup / dup2系统调用“复制”。

文件描述符在满足如下几个条件之一时候，会被释放：

进程退出
调用close函数
fork一个进程时，子进程中的所有描述符都“复制”。如果将任何描述符标记为close-on-exec，则在父分支之后但在子exec之前，子进程中的标记为close-on-exec的描述符将关闭，并且不再对子进程可用。父级仍然可以继续使用描述符，但子级执行后将无法使用它。

让我们假设在上面的示例中，进程A的描述符3标记有close-on-exec标志。如果进程A派生了进程B，那么在派生之后，进程A和进程B完全相同，因此进程B将“访问”文件描述符0、1、2和3。但是由于描述符3被标记为“执行时关闭”，因此在进程B执行之前，该描述符将被标记为“无效”，并且进程B将无法再访问它。

要真正理解这意味着什么，重要的是要了解描述符实际上只是指向（令人困惑地）文件描述的基础内核数据结构的每个进程的指针。内核维护一个包含所有打开文件描述的表，称为打开文件表。

假设进程A的fd3是由于描述符fd0通过dup或者fctl创建的。的文件描述。原始的fd3和复制的fd0都指向内核中同一块文件描述地址。

如果进程A然后分叉进程B，并且fd3被标记为close on exec标志，那么子进程B将继承父进程A的所有描述符，但不能使用fd3。

需要注意的是，子进程B中的fd0也将指向内核的open file表中相同的open file描述。

我们有三个描述符-进程A中的fd0和fd3以及进程B中的fd0-所有这些描述符都指向相同的内核文件描述块。需要注意的是，当一个进程fork另外一个进程时候，两个进程指向同一块内核文件描述块。且当其中某一个进程通过Unix域套接字套接字将文件描述符传递给另一个进程，则两个进程的描述符将再次指向相同的基础内核打开文件描述。最后，了解文件描述的inode指针字段是很重要的。但在此之前，重要的是要了解什么是inode。索引节点是文件系统数据结构，其中包含有关文件系统对象(文件或目录)信息。这些信息包括：

磁盘上存储文件或目录数据的块的位置
文件或目录的属性
有关文件或目录的附加元数据，如访问时间、所有者、权限等。

文件系统中的每个文件（和目录）都有一个inode条目，该条目是引用该文件的数字。此编号也称为索引节点编号。在许多文件系统上，最大索引节点数被限制为某个值，这意味着可以在系统上存储的文件总数也被限制。磁盘上有一个索引节点表条目，维护着索引号到磁盘上实际索引节点数据结构的映射。大多数文件系统都是通过内核的文件系统驱动程序访问的。该驱动程序使用索引节点号访问存储在索引节点中的信息。因此，为了知道文件或与该文件有关的任何元数据的位置，内核的文件系统驱动程序需要访问inode表。假设在进程A分支进程B之后，进程A又创建了两个文件描述符fd4和fd5。这些在流程B中没有重复。假设fd5是进程A的结果创建的，它在文件abc.txt上调用open进行读取。让我们假设进程B也调用openon abc.txt，但是对于写入和文件描述符，打开的返回给进程B的调用是fd10。然后，进程A的fd5和进程B的fd10指向打开文件表中的不同打开文件描述，但它们指向相同的inode表条目(或相同的文件)。

这有两个非常重要的含义：

由于进程A和进程B中的fd0引用相同的打开文件描述，因此它们共享文件偏移量。这意味着，如果进程A提前文件偏移量（通过调用read（）或write（）或lseek（）），则偏移量也会为进程B改变。这也适用于属于进程A的fd3，因为fd3引用了与fd0相同的打开文件描述。
这也适用于文件描述符在一个进程中对打开的文件状态标志（O_ASYNC，O_NONBLOCK，O_APPEND）进行的修改。因此，如果进程B通过fcntlsystem调用将O_NONBLOCK标志设置为fd0来将其设置为非阻塞模式，则属于进程A的描述符fd0和fd3也将开始观察非阻塞行为。

3 注意的点

让我们假设进程A有两个打开文件描述符fd0和fd1，它们在打开文件表中有两个打开文件描述。假设这两个文件描述都指向不同的inode。

epoll_create在内核中为其创建一个新的inode条目（epoll实例）以及一个打开文件描述，并向调用进程返回此打开文件描述的文件描述符(fd9)。

当我们使用epoll_ctl将文件描述符（例如fd0）添加到epoll实例的目标监控列表时，实际上是fd0的基础文件描述到epoll实例的目标监控列表中。

如果进程A派生了子进程B，则B继承了A的所有描述符，包括epoll描述符fd9。但是，进程B的描述符fd0，fd1和fd9仍引用相同的基础内核数据结构。进程B的epoll描述符（fd9）与流程A共享相同的目标监控列表。如果在fork之后，如果进程A创建通过epoll_ctl在其epoll目标监控列表中创建了一个新的描述符fd8（在进程B中未复制），则不仅仅是进程A在调用epoll_wait（）时会收到有关fd8事件的通知。如果进程B调用epoll_wait（），那么进程B也将获得有关fd8的通知（属于进程A，并且在派生进程中没有重复）。当通过调用dup / dup2或如果epoll文件描述符通过Unix域套接字传递给另一个进程来复制epoll文件描述符时，这也适用。

假设进程B通过新的open调用打开了fd8指向的文件，并因此获得了一个新的文件描述符（fd15）。现在假设进程A关闭了fd8。可以假定，由于进程A关闭了fd8，因此在调用epoll_wait时它将不再收到有关fd8事件的通知。但是，情况并非如此，因为目标监控列表会监视打开的文件说明。由于fd15指向与fd8相同的描述（因为它们都是相同的基础文件），因此进程A获得有关fd15上事件的通知。可以肯定地说，一旦文件描述符由进程使用epoll实例注册，那么即使关闭了描述符，该进程仍将继续获取有关描述符事件的通知，即使它关闭了该描述符通过至少一个其他描述符（属于相同或不同的进程）。

4 性能对比

众所周知，选择/轮询的时间复杂度为O（N），这意味着当N很大时（例如，Web服务器处理成千上万的大多数处于睡眠状态的客户端），每次调用选择/轮询时，即使实际只发生了少量事件，内核仍然需要扫描列表中的每个描述符。由于epoll监视基础文件描述，因此每次打开的文件描述为I / O准备就绪时，内核便将其添加到就绪列表中，而无需等待调用epoll_wait的进程来执行此操作。当某个进程确实调用epoll_wait时，那时内核不必做任何额外的工作来响应该调用，而是返回一直保持的有关就绪列表的所有信息。此外，每次选择/轮询的调用都需要向内核传递有关我们要监视的描述符的信息。从签名到两个调用，这都是显而易见的。内核返回有关传递的所有文件描述符的信息，该进程再次需要检查（通过扫描所有描述符）以找出哪些文件可用于I / O。

int poll(struct pollfd *fds, nfds_t nfds, int timeout);
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

使用epoll，一旦我们使用epoll_ctl调用将文件描述符添加到epoll实例的目标监控列表中，那么以后在调用epoll_wait时，我们就不需要随后传递我们希望查找其准备信息的文件描述符。与选择/轮询模型相反，内核再次只返回有关准备好进行I / O的描述符的信息，而选择/轮询模型则是内核返回有关传入的每个描述符的信息。结果，像选择/轮询那样，epoll的成本是O(发生的事件数 ), 而不是O(正在监视的描述符数)。

5 边沿触发

默认情况下，epoll使用水平触发的通知方式。每次对epoll_wait的调用仅返回已准备好的属于目标监控列表的文件描述符的子集。因此，如果我们注册了四个文件描述符（fd1，fd2，fd3和fd4），并且在调用epoll_wait时只有两个文件描述符（fd2和fd3）准备就绪，则仅返回有关这两个描述符的信息。

有意思的是，在默认水平触发的情况下，出于epoll的考虑，描述符的性质（阻塞与非阻塞）实际上不会影响epoll_wait的结果，因为epoll仅在以下情况下更新其就绪列表：基础的打开文件描述已准备就绪。有时我们可能只想在目标监控列表中查找任何描述符的状态（例如fd1），无论它是否准备就绪。epoll允许我们通过支持边缘触发的通知来确定是否可以在任何特定的文件描述符上进行I / O（即使在调用epoll_wait时尚未准备好）。如果我们想要有关自上一次调用epoll_wait以来（或者自从打开描述符以来，如果进程之前没有进行过epoll_wait调用）以来文件描述符上是否有任何I / O活动的信息，我们可以获取edge-向epoll实例注册文件描述符时调用epoll_ctl时，通过对EPOLLET标志进行或运算来触发通知。在实际项目中的代码中执行此操作可能会变得更有帮助，在实际项目中，文件描述符正在使用epoll_ctl向epoll实例注册，其中ePOLLET标志与一些其他标志一起进行“或”运算。下面，我们将通过一个例子，以便能够更清楚的理解epoll下边缘触发的工作方式。一个进程在epoll实例中注册了四个描述符。假设fd3是一个套接字，在时间t1，输入字节流到达fd3指向的套接字。

假设在时间点t4,进程调用了epoll_wait函数，同时，在该时间点，fd2和fd3准备就绪，则epoll_wait返回，并将fd2和fd3放入其就绪列表。

假设该进程在时间t6再次调用epoll_wait。假设fd1已准备就绪。我们还假设在时间t4和t6之间没有输入到达fd3所引用的套接字。在级别触发的情况下，对epoll_wait的调用将使fd1返回到进程，因为fd1是唯一准备好的描述符。但是，在边缘触发的情况下，此调用将阻塞，因为在时间t4和t6之间没有新数据到达fd3所引用的套接字。

6 例子

我们将以一个例子，来结束本文

static void set_nonblocking(int fd) {
  int flags = fcntl(fd, F_GETFL, 0);
  if (flags == -1) {
    perror("fcntl()");
    return;
  }
  if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) {
  }
}

int main(int argc, char **argv) {
  int sock = socket(AF_INET, SOCK_STREAM, 0);
  if (sock == -1) {
    perror("socket()");
    return 1;
  }
  int enable = 1;
  if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &enable, sizeof(enable)) ==
      -1) {
    perror("setsockopt()");
    return 1;
  }

  struct sockaddr_in addr;
  memset(&addr, 0, sizeof(addr));
  addr.sin_family = AF_INET;
  addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
  addr.sin_port = htons(PORT);
  if (bind(sock, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
    perror("bind()");
    return 1;
  }

  set_nonblocking(sock);
  if (listen(sock, SOMAXCONN) < 0) {
    perror("listen()");
    return 1;
  }

  int epoll_fd = epoll_create1(0);
  if (epoll_fd == -1) {
    perror("epoll_create1()");
    return 1;
  }

  struct epoll_event event;
  memset(&event, 0, sizeof(event));
  event.data.fd = sock;
  event.events = EPOLLIN | EPOLLET;
  if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, sock, &event) == -1) {
    perror("epoll_ctl()");
    return 1;
  }

  struct epoll_event *events = calloc(MAXEVENTS, sizeof(event));
  for (;;) {
    int nevents = epoll_wait(epoll_fd, events, MAXEVENTS, -1);
    if (nevents == -1) {
      return 1;
    }
    for (int i = 0; i < nevents; i++) {
      if ((events[i].events & EPOLLERR) || (events[i].events & EPOLLHUP) ||
          (!(events[i].events & EPOLLIN))) {
        close(events[i].data.fd);
        continue;
      } else if (events[i].data.fd == sock) {
        for (;;) {
          struct sockaddr in_addr;
          socklen_t in_addr_len = sizeof(in_addr);
          int client = accept(sock, &in_addr, &in_addr_len);
          if (client == -1) {
            if (errno == EAGAIN || errno == EWOULDBLOCK) {
              break;
            } else {
              return 1;
            }
          } else {
            set_nonblocking(client);
            event.data.fd = client;
            event.events = EPOLLIN | EPOLLET;
            if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, client, &event) == -1) {
              return 1;
            }
          }
        }
      } else {
        char buf[1024];
        for (;;) {
          ssize_t nbytes = read(events[i].data.fd, buf, sizeof(buf));
          if (nbytes == -1) {
            if (errno == EAGAIN || errno == EWOULDBLOCK) {
              break;
            } else {
              return 1;
            }
          } else if (nbytes == 0) {
            close(events[i].data.fd);
            break;
          } else {
            fwrite(buf, sizeof(char), nbytes, stdout);
          }
        }
      }
    }
  }
  return 0;
}