I/O 多路复用之 EPOLL

namelij

关注

发布于: 2021 年 03 月 26 日

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

语义

与 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 以确定哪些事件发生在哪些文件描述符上。

深入

要完全理解 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 也将开始观察非阻塞行为。

注意的点

让我们假设进程 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 实例注册，那么即使关闭了描述符，该进程仍将继续获取有关描述符事件的通知，即使它关闭了该描述符通过至少一个其他描述符（属于相同或不同的进程）。

性能对比

众所周知，选择/轮询的时间复杂度为 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(正在监视的描述符数)。

边沿触发

默认情况下，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 所引用的套接字。

例子

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

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;}