Unix/Linux编程：epoll详解

叁歲伎倆 2022-10-06 04:52 520阅读 0赞

同IO多路复用和信号驱动IO一样，Linux的epoll(event poll) API可以检查多个文件描述符上的IO就绪状态。epoll API的主要优点如下

*  当检查大量的文件描述符时，epoll的性能扩展性比select和poll高很多
 *  epoll API即支持水平触发也支持边缘触发。与之相反，select()和 poll()只支持水平触发，而信号驱动 I/O 只支持边缘触发

性能表现上，epoll与信号驱动IO类似。但是epoll有一些胜过信号驱动IO的优点

*  可以避免复杂的信号处理流程（比如信号队列溢出时的处理）
 *  灵活性高，可以指定我们希望检查的事件类型(比如，检测套接字文件描述符的读就绪、写就绪或者两种同时指定)

epoll API 是 Linux 系统专有的，在 2.6 版中新增

epoll API的核心数据结构称为epoll实例，它和一个打开的文件描述符相关联。这个文件描述符不是用来做IO操作的。相反，它是内核数据结构的句柄，这些内核数据结构实现了两个目的：

*  记录了在进程中声明过的感兴趣的文件描述符列表—interest list（兴趣列表）。
 *  维护了处于 I/O 就绪态的文件描述符列表—ready list（就绪列表）

ready list 中的成员是 interest list 的子集

对于由epoll检测的每一个文件描述符，我们可以指定一个位掩码来表示我们感兴趣的事件。这些位掩码同poll()所使用的位掩码有紧密的关联。

epoll API由下面三个系统调用组成

*  系统调用epoll\_create()创建一个epoll实例，返回代表该实例的文件描述符
 *  系统调用 epoll\_ctl()操作同 epoll 实例相关联的兴趣列表。通过 epoll\_ctl()，我们可以增加新的描述符到列表中，将已有的文件描述符从该列表中移除，以及修改代表文件描述符上事件类型的位掩码。
 *  系统调用 epoll\_wait()返回与 epoll 实例相关联的就绪列表中的成员。

## 创建epoll实例：epoll\_create() ##

系统调用epoll\_create()创建了一个新的epoll实例，其对应的兴趣列表初始化为空

NAME
           epoll_create, epoll_create1 - open an epoll file descriptor
    
    SYNOPSIS
           #include <sys/epoll.h>
    
           int epoll_create(int size);
           int epoll_create1(int flags);
    
    RETURN VALUE
           成功时，这些系统调用返回一个非负的文件描述符。 
           出错时，返回 -1，并设置 errno 以指示错误

### 参数 ###

> size

*  参数 size 指定了我们想要**通过 epoll 实例来检查的文件描述符个数**。
 *  该参数并不是一个上限，而是告诉内核应该如何为内部数据结构划分初始大小。
 *  （**从 Linux 2.6.8 版以来，size 参数被忽略不用**，因为内核实现做了修改意味着该参数之前提供的信息已经不再需要了。）

### 返回值 ###

作为函数返回值，epoll\_create()返回了代表新创建的 epoll 实例的文件描述符。

*  这个文件描述符在其他几个 epoll 系统调用中用来表示 epoll 实例。
 *  当这个文件描述符不再需要时，应该通过 close()来关闭。
 *  （**多个文件描述符可能引用到相同的 epoll 实例，这是由于调用了 fork()或者 dup()这样类似的函数所致**）
 *  **当所有与 epoll 实例相关的文件描述符都被关闭时，实例被销毁，相关的资源都返还给系统**。。

> 从 2.6.27 版内核以来，Linux 支持了一个新的系统调用 epoll\_create1()。
> 
>  *  该系统调用执行的任务同 epoll\_create()一样，但是去掉了无用的参数 size，并增加了一个可用来修改系统调用行为的 flags 参数。
>  *  目前只支持一个 flag 标志：EPOLL\_CLOEXEC，它使得内核在新的文件描述符上启动了执行即关闭（close-on-exec）标志（FD\_CLOEXEC）。
>  *  出于同样的原因，这个标志同 4.3.1 节中描述的 open()的 O\_CLOEXEC 标志一样有用。

### 最多能够创建多少个实例 ###

> max\_user\_watches 上限

*  因为每个注册到epoll实例上的文件描述符需要占用一小段不能被交换的内核内存空间，因此内核提供了一个接口用来定义每个用户可以注册到epoll实例上的文件描述符总数
 *  这个上限值可以通过 max\_user\_watches 来查看和修改。max\_user\_watches 是专属于 Linux 系统的/proc/sys/fd/epoll 目录下的一个文件。
 *  默认的上限值根据可用的系统内存来计算得出

### 示例 ###

int epfd=epoll_create(1);//只需要监听一个描述符——标准输入

## 修改 epoll 的兴趣列表：epoll\_ctl() ##

epoll\_ctl()能修改由文件描述符epfd所代表的epoll实例中的兴趣列表

NAME
           epoll_ctl - control interface for an epoll descriptor
    
    SYNOPSIS
           #include <sys/epoll.h>
    
           int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

### 参数 ###

> 参数`fd`

*  参数fd指定了要修改兴趣列表中的哪一个文件描述符的设定。
 *  该参数可以是代表管道、FIFO、套接字、POSIX 消息队列、inotify 实例、终端、设备，甚至是另一个 epoll 实例的文件描述符（例如，我们可以为受检查的描述符建立起一种层次关系）。
 *  但是，这里 fd 不能作为普通文件或目录的文件描述符（会出现 EPERM 错误）。  
    \-`EPERM`：**权限不被允许**

> 参数`op`

参数 op 用来指定需要执行的操作，它可以是如下几种值。

*  EPOLL\_CTL\_ADD
    
     *  将描述符 fd 添加到 epoll 实例 epfd 中的兴趣列表中去。
     *  对于 fd 上我们感兴趣的事件，都指定在 ev 所指向的结构体中。
     *  如果我们试图向兴趣列表中添加一个已存在的文件描述符，epoll\_ctl()将出现 EEXIST 错误。
 *  EPOLL\_CTL\_MOD
    
     *  修改描述符 fd 上设定的事件，需要用到由 ev 所指向的结构体中的信息。
     *  如果我们试图修改不在兴趣列表中的文件描述符，epoll\_ctl()将出现 ENOENT 错误。
 *  EPOLL\_CTL\_DEL
    
     *  将文件描述符 fd 从 epfd 的兴趣列表中移除。该操作忽略参数 ev。
     *  如果我们试图移除一个不在 epfd 的兴趣列表中的文件描述符，epoll\_ctl()将出现 ENOENT 错误。
     *  关闭一个文件描述符会自动将其从所有的 epoll 实例的兴趣列表中移除。

> 参数`ev`

参数 ev 是指向结构体 epoll\_event 的指针，结构体的定义如下。

typedef union epoll_data {
        
                   void        *ptr;   // pointer to user-defined data
                   int          fd;   // file descriptor
                   uint32_t     u32;  // 32-bit integer
                   uint64_t     u64;  // 64-bit integer
               } epoll_data_t;
    
               struct epoll_event {
        
                   uint32_t     events;      /* Epoll events */
                   epoll_data_t data;        /* User data variable */
               };

参数 ev 为文件描述符 fd 所做的设置如下。

*  结构体epoll\_event 中的events字段是一个位掩码，它指定了我们为待检查的描述符fd上所感兴趣的时间集合
 *  data字段是一个联合体，当描述符fd成为就绪态时，联合体的成员可以用来指定传回给调用进程的信息

### 示例 ###

int epfd;
    	struct epoll_event ev;
    	
        epfd = epoll_create(s);
        if (epfd == -1){
        
    		 errExit("epoll_create");
    	}
           
    
    	ev.data.fd = fd;
    	ev.events = EPOLLIN;
    	if(epoll_ctl(epfd, EPOLL_CTL_ADD, fd, ev) == -1){
        
    		 errExit("epoll_ctl");
    	}

## 事件等待：epoll\_wait() ##

epoll\_wait() 返回epoll实例中处于就绪态的文件描述符信息。单个epoll\_wait()调用能返回多个就绪态文件描述符的信息

NAME
           epoll_wait, epoll_pwait - wait for an I/O event on an epoll file descriptor
    
    SYNOPSIS
           #include <sys/epoll.h>
    
           int epoll_wait(int epfd, struct epoll_event *evlist,
                          int maxevents, int timeout);
           int epoll_pwait(int epfd, struct epoll_event *events,
                          int maxevents, int timeout,
                          const sigset_t *sigmask);

### 参数 ###

> 参数`evlist`

evlist所指向的结构体数组中返回的是有关就绪态文件描述符的信息。

evlist的空间由调用者负责申请，所包含的元素个数在参数maxevents中指定。

在数组evlist中，每个元素返回的都是单个就绪态文件描述符的信息。

*  events 字段返回了在该描述符上已经发生的事件掩码。
 *  data 字段返回的是我们在描述符上使用 cpoll\_ctl()注册感兴趣的事件时在 ev.data 中所指定的值。注意，data 字段是唯一可获知同这个事件相关的文件描述符号的途径。因此，当我们调用 epoll\_ctl()将文件描述符添加到兴趣列表中时，应该要么将 ev.data.fd 设为文件描述符号，要么将 ev.data.ptr 设为指向包含文件描述符号的结构体

> 参数 `timeout`

参数 timeout 用来确定 epoll\_wait()的阻塞行为，有如下几种。

*  如果 timeout 等于−1，调用将一直阻塞，直到兴趣列表中的文件描述符上有事件产生，或者直到捕获到一个信号为止。
 *  如果 timeout 等于 0，执行一次非阻塞式的检查，看兴趣列表中的文件描述符上产生了哪个事件。
 *  如果 timeout 大于 0，调用将阻塞至多 timeout 毫秒，直到文件描述符上有事件发生，或者直到捕获到一个信号为止

### 返回值 ###

*  调用成功后，epoll\_wait()返回数组 evlist 中的元素个数。
 *  如果在 timeout 超时间隔内没有任何文件描述符处于就绪态的话，返回 0。
 *  出错时返回−1，并在 errno 中设定错误码以表示错误原因。

>  *  在多线程程序中，可以在一个线程中使用epoll\_ctl()将文件描述符添加到另一个线程中有epoll\_wait()所监视的epoll实例的兴趣列表中去。
>  *  这些对兴趣列表的修改将立刻得到处理，而epoll\_wait()调用将返回有关新添加的文件描述符的就绪信息。

### 返回的条件 ###

epoll\_wait返回的条件是rdlist不空，而使rdlist不空的途径有两个。

#### 1. 文件描述符状态的改变 ####

##### 【对于读操作】 #####

*  当buffer由**不可读状态变为可读**的时候，即**由空变为不空**的时候。  
    ![在这里插入图片描述][b16cca5be39a4b8b9af8ab47f08e1201.png]
 *  当有**新数据到达**时，即buffer中的**待读内容变多**的时候。  
    ![在这里插入图片描述][665ad16e3770463cb14ad902a1e1c8e7.png]

##### 【对于写操作】： #####

*  当buffer由**不可写变为可写**的时候，即由**满状态变为不满**状态的时候。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]
 *  当有**旧数据被发送走**时，即buffer中**待写的内容变少**的时候。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]

#### 2. 文件描述符的事件位events置1 ####

##### 【对于读操作】： #####

*  buffer中有数据可读的时候，**即buffer不空的时候fd的events的可读位就置1**。

##### 【对于写操作】： #####

*  buffer中有空间可写的时候，**即buffer不满的时候fd的events的可写位就置1**。

![在这里插入图片描述][7c7a2984a9c141c68d81aef9f6eac41b.png]

#### 说明 ####

ET和LT模式下的epitem都可以通过途径1加入rdlist从而唤醒epoll\_wait，但LT模式下的epitem还可以通过途径2重新加入rdlist唤醒epoll\_wait。

**从源码角度看，ET模式下，文件描述符fd只会加入rdlist一次，所以epoll\_wait只会被触发一次，然后移除此epitem；而LT模式下只要满足相应读写条件就会再次加入rdlist，epoll\_wait会被触发多次**。

## epoll事件 ##

当我们调用epoll\_ctl()时可以在ev.events中指定的位掩码以及由epoll\_wait()返回的evlist\[\].events 中的值如下表。

除了有一个额外的前缀 E 外，大多数这些位掩码的名称同 poll()中对应的事件掩码名称相同。这种名称上有着对应关系的原因是当我们在 epoll\_ctl()中指定输入，或通过 epoll\_wait()得到输出时，这些比特位表达的意思同对应的 poll()的事件掩码所表达的意思一样

<table> 
 <thead> 
  <tr> 
   <th>位掩码</th> 
   <th>作为 epoll_ctl()的输入？</th> 
   <th>由 epoll_wait()返回？</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>EPOLLIN</td> 
   <td>●</td> 
   <td>●</td> 
   <td>可读取非高优先级的数据</td> 
  </tr> 
  <tr> 
   <td>EPOLLPRI</td> 
   <td>●</td> 
   <td>●</td> 
   <td>可读取高优先级数据</td> 
  </tr> 
  <tr> 
   <td>EPOLLRDHUP</td> 
   <td>●</td> 
   <td>●</td> 
   <td>套接字对端关闭（始于 Linux 2.6.17 版）</td> 
  </tr> 
  <tr> 
   <td>EPOLLOUT</td> 
   <td>●</td> 
   <td>●</td> 
   <td>普通数据可写</td> 
  </tr> 
  <tr> 
   <td>EPOLLET</td> 
   <td>●</td> 
   <td></td> 
   <td>采用边缘触发事件通知</td> 
  </tr> 
  <tr> 
   <td>EPOLLONESHOT</td> 
   <td>●</td> 
   <td></td> 
   <td>在完成事件通知之后禁用检查</td> 
  </tr> 
  <tr> 
   <td>EPOLLERR</td> 
   <td></td> 
   <td>●</td> 
   <td>有错误发生</td> 
  </tr> 
  <tr> 
   <td>EPOLLHUP</td> 
   <td></td> 
   <td>●</td> 
   <td>出现挂断</td> 
  </tr> 
 </tbody> 
</table>

#### EPOLLONESHOT 标志 ####

*  默认情况下，一旦通过 epoll\_ctl()的 EPOLL\_CTL\_ADD 操作将文件描述符添加到 epoll 实例的兴趣列表中后，它会保持激活状态（即，之后对 epoll\_wait()的调用会在描述符处于就绪态时通知我们），直到我们显式地通过 epoll\_ctl()的 EPOLL\_CTL\_DEL 操作将其从列表中移除
 *  如果我们希望在某个特定的文件描述符上只得到一次通知，那么可以在传给 epoll\_ctl()的ev.events 中指定`EPOLLONESHOT`（从 Linux 2.6.2 版开始支持）标志。如果指定了这个标志，那么在下一个 epoll\_wait()调用通知我们对应的文件描述符处于就绪态之后，这个描述符就会在兴趣列表中被标记为非激活态，之后的 epoll\_wait()调用都不会再通知我们有关这个描述符的状态了。
 *  如果需要，我们可以稍后通过 epoll\_ctl()的`EPOLL_CTL_ MOD` 操作重新激活对这个文件描述符的检查。（这种情况下不能用 EPOLL\_CTL\_ADD 操作，因为非激活态的文件描述符仍然还在 epoll 实例的兴趣列表中。

# 深入探究epoll的语义 #

当我们通过epoll\_create()创建一个epoll实例时，内核在内存中创建了一个新的i-node并打开文件描述，随后在调用进程中为打开的这个文件描述分配一个新的文件描述符。同epoll实例的兴趣列表相关联的是打开的文件描述，而不是epoll文件描述符。这将产生下列结果：

*  如果我们使用 dup()（或类似的函数）复制一个 epoll 文件描述符，那么被复制的描述符所指向的 epoll 兴趣列表和就绪列表同原始的 epoll 文件描述符相同。
 *  上一条观点同样也适用于 fork()调用之后的情况。此时子进程通过继承复制了父进程的 epoll 文件描述符，而这个复制的文件描述符所指向的 epoll 数据结构同原始的描述符相同

当我们指向epoll\_ctl()的EPOLL\_CTL\_ADD操作时，内核在epoll兴趣列表中添加了一个元素，这个元素同时记录了需要检查的文件描述符数量以及对应的打开文件描述的引用。**epoll\_wait()调用的目的就是让内核负责监视打开的文件描述**。

这表示我们必须对之前的观点做改进：如果一个文件描述符是 epoll 兴趣列表中的成员，当关闭它后会自动从列表中移除。改进版应该是这样的：**一旦所有指向打开的文件描述的文件描述符都被关闭后，这个打开的文件描述将从 epoll 的兴趣列表中移除**。这表示如果我们通过 dup()（或类似的函数）或者 fork()为打开的文件创建了描述符副本，那么这个打开的文件只会在原始的描述符以及所有其他的副本都被关闭时才会移除

> 文件描述符 VS 文件描述
> 
>  *  文件描述表示的是一个打开文件的上下文信息息（大小、内容、编码等与文件有关的信息），可以比喻为一个抽屉，这部分内容实际上是由内核来管理的。
>  *  而用户空间的应用程序如果要操作文件怎么办。就是通过 open()这样的系统调用向内核请求，然后内核分配给用户空间一个文件描述符（file descriptor）。
>  *  这个文件描述符可以比喻为抽屉的把手（handle之所以翻译为“句柄”，这就是原因），有了这个把手（文件描述符），用户就可以操作抽屉（文件描述）里的内容了。
>  *  但是，一个抽屉可以有多个把手（即文件描述可以对应多个文件描述符），只有当所有的把手（文件描述符）都关闭了，内核就知道此时没有用户空间的程序要用这个抽屉了（文件描述），那么就把它回收。
> 
> 文件描述实际上是内核中的一个数据结构，而用户空间中的文件描述符不过是一个整数，epoll的兴趣列表实际关注的是内核中的数据结构

# epoll触发模式 #

select(),poll()模型都是水平触发模式，信号驱动IO是边缘触发模式，epoll()模型即支持水平触发，也支持边缘触发，默认是水平触发 。

> 简单点描述就是：网卡收到包以后，会把它的接口设置一个电势差。操作系统的驱动层其实是会一直去扫描网卡的接口的电势差的。
> 
>  *  LT: 水平触发，就是只要电势差存在就触发。在接收包的队列清空以前不reset网卡接口的电势差。也就是说你不接收完包就会一直触发中断事件。
>  *  ET:  
>     边缘触发，就是发现电势差存在以后，先把电势差reset了，然后触发中断事件。于是乎你在应用层就要尝试把网卡的队列清空，否则后面就没有事件通知了。

## 水平触发(TL) ##

>  *  level trigger，LT
>  *  默认工作模式
>  *  **只要内核缓冲区有数据就一直通知，只要socket处于可读状态或可写状态，就会一直返回sockfd**
>  *  LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket

*  当epoll\_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用epoll\_wait时，会再次响应应用程序并通知此事件。
 *  使用此种模式，当数据可读的时候，epoll\_wait（）将会一直返回就绪事件。如果你没有处理完全部数据，并且再次在该epoll实例上调用epoll\_wait（）才监听描述符的时候，它将会再次返回就绪事件，因为有数据可读

> **在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你 的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表**

## 边缘触发 ##

>  *  edge trigger，ET
>  *  **只有状态发生变化才通知，只有当socket由不可写到可写或由不可读到可读，才会返回其sockfd**
>  *  ET (edge-triggered)是**高速工作方式**，只支持no-block socket

*  当epoll\_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件。如果不处理，下次调用epoll\_wait时，不会再次响应应用程序并通知此事件。
 *  使用此种模式，只能获取一次就绪通知，如果没有处理完全部数据，并且再次调用epoll\_wait()的时候，它将会阻塞，因为就绪事件已经释放出来了
 *  使用 epoll 的边缘触发通知在语义上类似于信号驱动 I/O，只是如何有多个IO事件发生的话，epoll会将它们合并成一次单独的通知，通过epoll\_wait返回，而在信号驱动IO则可能会产生多个信号

> ET (edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述 符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致 了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)

### 设置 ###

要使用边缘触发通知，我们在调用epoll\_ctl时在ev.events字段中指定EPOLLET标志：

struct epoll_event ev;
    		
    		ev.data.fd = fd;
    		ev.evengs = EPOLLIN | EPOLLET;
    		if (epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev) == -1){
        
                perror("epoll_ctl EPOLL_CTL_ADD");
                exit(EXIT_FAILURE);
            }

### 采用epoll的边缘触发通知机制的程序的基本框架 ###

**边缘触发通知通常和非阻塞的文件描述符结合使用**。因此，采用epoll的边缘触发通知机制的程序的基本框架如下：

*  让所有待监视的文件描述符都成为非阻塞的
 *  通过epoll\_ctl构建epoll的兴趣列表
 *  通过如下的循环处理IO事件
    
     *  通过epoll\_wait()取得出于就绪态的描述符列表
     *  针对每一个出于就绪态的文件描述符，不断进行IO处理直到相关的系统调（例如 read()、write()、recv()、send()或 accept()）返回 EAGAIN 或 EWOULDBLOCK  
        错误）

### 当采用边缘触发通知时避免出现文件描述符饥饿现象 ###

#### 什么叫做文件描述符饥饿现象 ####

*  假设我们采用边缘触发通知监视多个文件描述符，其中一个处于就绪态的文件描述符上有着大量的输入存在（可能是一个不间断的输入流）。
 *  如果在检测到该文件描述符处于就绪态后，我们将尝试通过非阻塞式的读操作将所有的输入都读取，那么此时就会有使其他的文件描述符处于饥饿状态的风险存在（即，在我们再次检查这些文件描述符是否处于就绪态并执行 I/O 操作前会有很长的一段处理时间）。

#### 解决方案 ####

该问题的一种解决方案是**让应用程序维护一个列表，列表中存放着已经被通知为就绪态的文件描述符**。通过一个循环按照如下方式不断处理。

*  调用 epoll\_wait()监视文件描述符，并将**处于就绪态的描述符添加到应用程序维护的列表中**。
    
     *  如果这个文件描述符已经注册到应用程序维护的列表中了，那么这次监视操作的超时时间应该设为较小的值或者是 0。
     *  这样如果没有新的文件描述符成为就绪态，应用程序就可以迅速进行到下一步，去处理那些已经处于就绪态的文件描述符了。
 *  在应用程序维护的列表中，只在那些**已经注册为就绪态的文件描述符**上进行一定限度的 I/O 操作
    
     *  （可能是以轮转调度（round-robin）方式循环处理，而不是每次epoll\_wait()调用后都从列表头开始处理）。
     *  当相关的非阻塞 I/O 系统调用出现 EAGAIN 或EWOULDBLOCK 错误时，文件描述符就可以从应用程序维护的列表中移除了。

因为信号驱动 I/O 也是采用的边缘触发通知机制，因此也需要考虑文件描述符饥饿的情况。

#### 水平触发有没有文件描述符饥饿现象 ####

与之相反，在采用水平触发通知机制的应用程序中，考虑文件描述符饥饿的情况并不是必须的。

*  这是因为我们可以采用水平触发通知在非阻塞式的文件描述符上通过循环连续地检查描述符的就绪状态
 *  然后在下一次检查文件描述符的状态前在处于就绪态的描述符上做一些 I/O 处理就可以了

# 实例 #

## 实例1：不读出数据的ET和LT ##

#include <stdio.h>
    #include <unistd.h>
    #include <sys/epoll.h>
    
    int main(void)
    {
        
        int epfd,nfds;
    
        //用于添加事件
        struct epoll_event ev;
    
        //用于存放检测到的事件
        struct epoll_event events[5];
    
        //创建一个epoll实例
        epfd = epoll_create(1);
    
        //设置事件参数
        ev.data.fd =STDIN_FILENO;
    
        //设置为检测读事件，默认时水平触发(LT)
        ev.events = EPOLLIN;
    
        //设置为检测读事件，默认时边沿触发(ET)
      //  ev.events = EPOLLIN | EPOLLET;
    
        //注册事件
        epoll_ctl(epfd,EPOLL_CTL_ADD,STDIN_FILENO,&ev);
    
        while(1)
        {
        
            //等待事件发生,返回值是发生事件的数目
            nfds = epoll_wait(epfd,events,5,-1);
    
            int i;
    
            //遍历处理
            for(i=0;i<nfds;++i)
            {
        
                if(!(events[i].events & EPOLLIN))
                {
        
                    continue;
                }
    
                if(events[i].data.fd == STDIN_FILENO)
                {
        
                    printf("welcome to epoll's world!\n");
                }
            }
        }
    
        //关闭描述符(句柄)
        close(epfd);
    
    
        return 0;
    }

### 现象 ###

> 当前为LT模式，并且数据没有读走：

**程序出现死循环，因为用户输入任意数据之后，数据被送入buffer而且没有被读出，所以LT模式下每次epoll\_wait都认为buffer可读返回读就绪，导致不断输出"welcome to epoll’s world!\\n"**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]

> 当前为ET模式，并且数据没有读走：

*  当用户输入一组字符，**这组字符被送入`buffer`**，字符停留在buffer中，又因为**buffer由空变为不空，所以ET返回读就绪**，输出"welcome to epoll’s world!\\n"
 *  之后程序再次执行epoll\_wait，**此时虽然buffer中有内容可读，但是ET并不返回就绪（只有当buffer由空变为不空或者有新数据到达才返回就绪），导致epoll\_wait阻塞。**（底层原因是ET下就绪fd的epitem只被放入rdlist一次）。
 *  用户再次输入一组字符，导致**buffer中的内容增多（有新数据到达），这将导致fd状态的改变**，对应的epitem再次加入rdlist，从而使epoll\_wait返回读就绪，再次输出“hello world！”。  
    ![在这里插入图片描述][3514daf8b80d44699dc65dc664674ac9.png]

## 实例2：读出数据的ET和LT ##

#include <stdio.h>
    #include <unistd.h>
    #include <sys/epoll.h>
    
    int main(void)
    {
        
        int epfd,nfds;
    
        //用于添加事件
        struct epoll_event ev;
    
        //用于存放检测到的事件
        struct epoll_event events[5];
    
        //创建一个epoll实例
        epfd = epoll_create(1);
    
        //设置事件参数
        ev.data.fd =STDIN_FILENO;
    
        //设置为检测读事件，默认时水平触发(LT)
        ev.events = EPOLLIN;
    
        //设置为检测读事件，默认时边沿触发(ET)
       // ev.events = EPOLLIN | EPOLLET;
    
        //注册事件
        epoll_ctl(epfd,EPOLL_CTL_ADD,STDIN_FILENO,&ev);
    
        while(1)
        {
        
            //等待事件发生,返回值是发生事件的数目
            nfds = epoll_wait(epfd,events,5,-1);
    
            int i;
    
            //遍历处理
            for(i=0;i<nfds;++i)
            {
        
                if(!(events[i].events & EPOLLIN))
                {
        
                    continue;
                }
    
                if(events[i].data.fd == STDIN_FILENO)
                {
        
                    char buffer[256] = {
        0};
    
                    read(STDIN_FILENO,buffer,sizeof(buffer));
    
                    printf("input:%s",buffer);
    
                    printf("welcome to epoll's world!\n");
                }
            }
        }
    
        //关闭描述符(句柄)
        close(epfd);
    
    
        return 0;
    }

### 现象 ###

> 当前为LT模式，并且数据读走了：

*  首次调用epoll\_wait时，STDIN\_FILENO描述符上没有数据可读，因此阻塞
 *  然后用户输入数据，epoll\_wait发现**buffer中有数据可读**，因此不在阻塞，就会返回读就绪
 *  返回后，程序使用了将buffer（缓冲）中的内容read出来，也就是说**buffer已经清空了**，因此，下一次再调用epoll\_wait就会阻塞

简单的来说，LT模式下**每次epoll\_wait返回读就绪的时候我们都将buffer（缓冲）中的内容read出来，所以导致buffer再次清空，下次调用epoll\_wait就会阻塞。**

![在这里插入图片描述][df9dad1f49f649f38f0c6ab3df236499.png]

> 当前为ET模式，并且数据读走了：

*  刚开始时，epoll\_wait会阻塞，直到用户输入数据，此时**buffer由空变为非空**，epoll\_wait就会将当前epitem加入就绪列表，然后返回读就绪
 *  当epoll\_wait返回后，程序调用read就buffer中的内容清空。因此，下一个调用epoll\_wait时仍会阻塞，也就是回到了第一步

![在这里插入图片描述][df9dad1f49f649f38f0c6ab3df236499.png]

## 实例3：写数据的ET模式 ##

#include <unistd.h>
    #include <iostream>
    #include <sys/epoll.h>
    using namespace std;
    int main(void)
    {
        
        int epfd,nfds;
        struct epoll_event ev,events[5];//ev用于注册事件，数组用于返回要处理的事件
        epfd=epoll_create(1);//只需要监听一个描述符——标准输出
        ev.data.fd=STDOUT_FILENO;
        ev.events=EPOLLOUT|EPOLLET;//监听读状态同时设置ET模式
        epoll_ctl(epfd,EPOLL_CTL_ADD,STDOUT_FILENO,&ev);//注册epoll事件
        //   cout<<"****";
        for(;;)
        {
        
         //   cout<<"****";
            nfds=epoll_wait(epfd,events,5,-1);
            for(int i=0;i<nfds;i++)
            {
        
                if(events[i].data.fd==STDOUT_FILENO){
        
                    cout<<"hello world!\n";
                  //  cout<<"hello world!";
                }
    
            }
        }
    };

### 现象 ###

> `cout<<"hello world!\n";`

*  **初始时buffer为空，buffer中有空间可以写，因此ET将对应的epitme加入rdlist，导致epoll\_wait返回写就绪**
 *  程序想标准输出输出”hello world！”和换行符，因为标准输出为控制台时缓冲是“行缓冲”，所以**换行符导致buffer中的内容清空 -----当有旧数据被发送走的时候**，也就是说buffer中待写的内容变少得时候**会触发fd状态的改变**。所以下次epoll\_wait会返回写就绪。之后重复这个过程一直循环下去  
    ![在这里插入图片描述][37e23565b4684faea075f3856a617948.png]

> `cout<<"hello world!"`

我们看到程序成挂起状态。

*  因为第一个`epoll_wait`返回写就绪之后，程序向标准输出的buffer中写入“hello world!"”，所以**buffer中的内容一直存在**，下次epoll\_wait的时候，虽然有写空间但是ET模式下不再返回写就绪。这种情况的原因是**第一次buffer为空，导致epitem加入rdlist，返回一次就绪后移除此epitem**，之后虽然buffer仍然可写，但是由于**对应epitem已经不在rdlist**中，就不会对其就绪fd的events的在检测了  
    ![在这里插入图片描述][6b5d1233ee284719a4b50e07939d615e.png]

## 实例4：写数据的LT模式 ##

#include <unistd.h>
    #include <iostream>
    #include <sys/epoll.h>
    using namespace std;
    int main(void)
    {
        
        int epfd,nfds;
        struct epoll_event ev,events[5];//ev用于注册事件，数组用于返回要处理的事件
        epfd=epoll_create(1);//只需要监听一个描述符——标准输出
        ev.data.fd=STDOUT_FILENO;
        ev.events=EPOLLOUT;//监听读状态同时设置ET模式
        epoll_ctl(epfd,EPOLL_CTL_ADD,STDOUT_FILENO,&ev);//注册epoll事件
    
        for(;;)
        {
        
    
            nfds=epoll_wait(epfd,events,5,-1);
            for(int i=0;i<nfds;i++)
            {
        
                if(events[i].data.fd==STDOUT_FILENO){
        
                    //  cout<<"hello world!\n";
                   cout<<"hello world!";
                }
    
            }
        }
    };

使用默认的LT模式，程序再次死循环。这时候原因已经很清楚了，因为当向buffer写入”hello world!”后，**虽然buffer没有输出清空，但是LT模式下只要buffer有写空间就返回写就绪**，所以会一直输出”hello world!”,当buffer满的时候，buffer会自动刷清输出，同样会造成epoll\_wait返回写就绪。

# 问题 #

## ET模式下的读写注意事项 ##

### 解决方法（非阻塞模式） ###

经过前面的分析，我们可以知道，当epoll工作在ET模式下时：

*  对于读操作，**如果read一次没有读尽buffer中的数据，那么下次将得不到读就绪的通知，造成buffer中的已有数据没有机会读出，除非有新的数据再次到达**。
 *  对于写操作，主要是因为ET模式下fd通常为非阻塞造成的一个问题-----**如何保证将用户要求的数据写完**

要解决上面两个ET模式下的读写问题，我们必须实现：

*  对于读，**只要buffer中还有数据就一直读**
 *  对于写，**只要buffer还有空间且用户请求写的数据还未写完，就一直写**

if (events[i].events & EPOLLIN) 
    {
        
    	n = 0;
    	// 一直读直到返回0或者 errno = EAGAIN
        while ((nread = read(fd, buf + n, BUFSIZ-1)) > 0) 
      	{
        
      		n += nread;
        }
     	if (nread == -1 && errno != EAGAIN) 
    	{
        
    		perror("read error");
    	}
        ev.data.fd = fd;
        ev.events = events[i].events | EPOLLOUT;
        epoll_ctl(epfd, EPOLL_CTL_MOD, fd, &ev);
    }
    
    if (events[i].events & EPOLLOUT) 
    {
         
    	int nwrite, data_size = strlen(buf);
    	n = data_size;
    	while (n > 0) 
    	{
        
    		nwrite = write(fd, buf + data_size - n, n);
    		if (nwrite < n) 
    		{
        
    			if (nwrite == -1 && errno != EAGAIN) 
    			{
        
    				perror("write error");
    			}
    			break;
    		}
    		n -= nwrite;
    	}
    	ev.data.fd=fd; 
    	ev.events=EPOLLIN|EPOLLET; 
    	epoll_ctl(epfd,EPOLL_CTL_MOD,fd,&ev);  //修改sockfd上要处理的事件为EPOLIN
    }

使用这种方式**一定要使得每个连接的套接字工作在非阻塞模式**，因为**读写需要一直读或者写直到出错**（对于读，当读到的实际字节数小于请求字节数时就可以停止），而**如果你的文件描述符如果不是非阻塞的，那这个一直读或一直写势必会在最后一次阻塞（最后一次read肯定要返回0，表示缓冲区没有数据可读了，因此最后一次read会阻塞**）。这样就不能在阻塞在epoll\_wait上了，造成其他文件描述符的任务饿死。

### EAGAIN ###

在Linux环境下开发经常会碰到很多错误(设置errno)，其中EAGAIN是其中比较常见的一个错误(比如用在非阻塞操作中)。

*  从字面上来看，是提示再试一次。这个错误经常出现在当应用程序进行一些非阻塞(non-blocking)操作(对文件或socket)的时候。
    
     *  如果你连续做read操作而没有数据可读。
     *  此时程序不会阻塞起来等待数据准备就绪返回，read函数会返回一个错误EAGAIN，提示你的应用程序现在没有数据可读请稍后再试。
 *  又例如，当一个系统调用(比如fork)因为没有足够的资源(比如虚拟内存)而执行失败，返回EAGAIN提示其再调用一次(也许下次就能成功)。

### 上述方法中写操作的改进 ###

仔细分析上述的写操作，我们发现这种方式并不很完美，**因为写操作返回EAGAIN就终止写，但是返回EAGAIN只能说名当前buffer已满不可写，并不能保证用户（或服务端）要求写的数据已经写完**。那么如何保证对非阻塞的套接字写够请求的字节数才返回呢（阻塞的套接字直到将请求写的字节数写完才返回）?

我们需要封装socket\_write()的函数用来处理这种情况,该函数会尽量将数据写完再返回，返回-1表示出错。在socket\_write()内部，**当写缓冲已满(send()返回-1,且errno为EAGAIN)，那么会等待后再重试**。

ssize_t socket_write(int sockfd, const char* buffer, size_t buflen)
    {
        
    	ssize_t tmp;
      	size_t total = buflen;
      	const char* p = buffer;
      	while(1)
      	{
        
        	tmp = write(sockfd, p, total);
        	if(tmp < 0)
        	{
        
    	      // 当send收到信号时,可以继续写,但这里返回-1.
     	     if(errno == EINTR)
      	      return -1;
      	    // 当socket是非阻塞时,如返回此错误,表示写缓冲队列已满,
      	    // 在这里做延时后再重试.
     	    if(errno == EAGAIN)
     	    {
        
     	    	usleep(1000);
            	continue;
          	}
          	return -1;
        }
        if((size_t)tmp == total)
        	return buflen;
        total -= tmp;
        p += tmp;
      }
      return tmp;//返回已写字节数
    }

## ET模式下的accept注意事项 ##

考虑这种情况：多个连接同时到达，服务器的 TCP 就绪队列瞬间积累多个就绪连接，**由于是边缘触发模式，epoll 只会通知一次，accept 只处理一个连接，导致 TCP 就绪队列中剩下的连接都得不到处理**。

解决办法是用**while 循环抱住 accept 调用，处理完 TCP 就绪队列中的所有连接后再退出循环**。如何知道是否处理完就绪队列中的所有连接呢？**accept 返回 -1 并且 errno 设置为 EAGAIN 就表示所有连接都处理完**。

while ((conn_sock = accept(listenfd,(struct sockaddr *) &remote, 
    		(size_t *)&addrlen)) > 0)
    {
        
    	handle_client(conn_sock);
    }
    if (conn_sock == -1)
    {
        
    	if (errno != EAGAIN && errno != ECONNABORTED && 
    		errno != EPROTO && errno != EINTR)
    		perror("accept");
    }

## 多路IO复用accept为什么应该工作在非阻塞模式 ##

如果`accept`工作在阻塞模式，考虑这种情况：TCP连接被客户端夭折，即在服务器调用 accept 之前（此时select等已经返回连接到达读就绪），**客户端主动发送RST终止连接，导致刚刚建立的连接从就绪队列中移除，如果套接字被设置成阻塞模式，服务器就会一直阻塞在accept调用上，直到其他某个客户建立一个新的连接为止**。但是在此期间，服务器单纯的阻塞在accept调用上（实际应该阻塞在select上），就绪队列中的其他描述符都得不到处理。

**解决方法是把监听套接字设置为非阻塞，当客户在服务器调用accept之前终止某个连接时，accept调用可以立即返回-1**。这时源自 Berkeley 的实现会在内核中处理该事件，并不会将该事件通知给 epoll，而其他实现把 errno 设置为 ECONNABORTED 或者 EPROTO 错误，我们应该忽略这两个错误

## LT模式下会不停触发socket可写事件，如何处理？ ##

*  **需要向socket写数据的时候才把socket加入epoll，等待可写事件。接收到可写事件后，调用write或者send发送数据。接受到可写事件后，调用write或者send发送数据。当所有数据都写完后，把socket移出epoll。**
 *  **使用ET模式**（边沿触发），这样socket有可写事件，只会触发一次。
 *  在epoll\_ctl()使用**EPOLLONESHOT**标志，当事件触发以后，socket会被禁止再次触发。

## epoll读到一半又有新事件来了怎么办 ##

> 最直接的方法： **不要多个线程读写同一个 TCP 连接**。

> 待研究的方法： `EPOLL_ONESHOT`

## Epoll+LT 模式下，客户端发异常报文，如何处理 ##

> 回答：

*  这个其实和 epoll 或者 LT 模式没关系的，其实就是客户端不根据协议规定格式，给服务器发送非法数据。服务器的资源是有限的，要尽可能给更多的正常客户端服务，对于这类不按协议格式发送数据的客户端即可认为是非法客户端，一般直接关闭该路连接就行了。
 *  当然，在实际的商业项目中，如果一个主机或者ip总是这样非法发数据，会被记录到服务器的黑名单中，直接在连接时就断开了。

> 回答：

*  **客户端不按协议来，是客户端的锅，发现边界不对或第二个包头特征不对时就应该关闭连接了**

> 回答：

协议设计的问题，一般的原则是：

*  无论客户端发送什么都不可以对服务端造成致命影响，比如崩溃或者拒绝服务
 *  无论客户端发送什么都不可以对其他用户或者有价值的数据造成破坏
 *  除此之外的后果可以让这个客户端自己负责

因此一般的设计方法是：

*  如果解析某个字段可能导致安全问题，比如使用了过多的内存导致内存溢出等等，则相关的字段需要进行强校验；
 *  如果客户端长时间保持连接不响应可能导致连接耗尽，则相应的步骤需要设超时（实际上由于TCP的特性，所有的状态都应该有超时）
 *  对于需要授权的操作必须进行认证
 *  除此以外的问题都通过异常处理来解决，一旦发现协议解析失败就返回错误或者直接断开连接

用Epoll并不会改变这个结论

顺便说一下，checksum并没有太大作用，它只能防止物理故障和无意导致的错误，无法防止故意发送的错误，而且TCP层已经有checksum了。magic可以部分防止接受到错误协议的请求，但也并不根本性解决问题。

[来自][Link 1]

## 使用epoll时需要将socket设为非阻塞吗？【待研究】 ##

> 一个 socket 是否设置为阻塞模式，只会影响到 connect/accept/send/recv 等四个 socket API 函数，不会影响到 select/poll/epoll\_wait 函数，后三个函数的超时或者阻塞时间是由其函数自身参数控制的。

[来自][Link 2]

## epoll 同 I/O 多路复用的性能对比 ##

随着被监视的文件描述符数量的上升，poll()和 select()的性能表现越来越差。与之相反，当 N 增长到很大的值时，epoll 的性能表现几乎不会降低

为什么 epoll 的性能表现会更好？

> （1）

*  每次调用select和poll时，内核必须检查所有在调用中指定的文件描述符。
 *  与之相反，当通过epoll\_ctl指定了需要监视的文件描述符时，内核会在与打开的文件描述上下文相关联的列表中记录该描述符。
 *  之后每当执行IO操作使得文件描述符成为就绪态时，内核就在epoll描述符的就绪列表中添加一个元素（单个打开的文件描述上下文中的一次 I/O 事件可能导致与之相关的多个文件描述符成为就绪态）。
 *  之后的epoll\_wait()调用就从就绪列表中简单的取出这些元素

> （2）

*  每次调用select或者poll时，
    
     *  我们传递了一个标记了所有待监视的文件描述符的数据结构给内核，
     *  调用返回时，内核将所有标记为就绪态的文件描述符的数据结构再传回给我们。
 *  与之相反，在epoll中：
    
     *  我们使用epoll\_ctl在内核空间中建立一个数据结构，该数据结构会将待监视的文件描述符都记录下来。
     *  一旦这个数据结构建立完成， 稍后每次调用epoll\_wait时就需要不再传递任何与文件描述符相关的信息给内核了
     *  而调用返回的信息只包含那些已经出于就绪态的描述符

epoll API 的**应用场景**就是需要同时处理许多客户端的服务器：**需要监视大量的文件描述符，但大部分出于空闲状态，只有少数文件描述符出于就绪态**

# 实例 #

## 例子 ##

#include <sys/epoll.h>
    #include <fcntl.h>
    
    #define MAX_BUF     1000        /* 单个 read() 获取的最大字节数  */
    #define MAX_EVENTS     5        /* 从单个 epoll_wait() 调用返回的最大事件数 */
    int main(int argc, char *argv[]){
        
        int epfd, ready, fd, s, j, numOpenFds;
        struct epoll_event ev;
        struct epoll_event evlist[MAX_EVENTS];
        char buf[MAX_BUF];
    
        if (argc < 2 || strcmp(argv[1], "--help") == 0){
        
            printf("%s file...\n", argv[0]);
            exit(EXIT_FAILURE);
        }
    
        //创建一个 epoll 实例
        epfd = epoll_create(argc - 1);
        if (epfd == -1){
        
            perror("epoll_create");
            exit(EXIT_FAILURE);
        }
    
        /* Open each file on command line, and add it to the "interest
          list" for the epoll instance */
    
        for (j = 1; j < argc; j++) {
        
            // 打开由命令行参数指定的每个文件，以此作为输入
            fd = open(argv[j], O_RDONLY);
            if (fd == -1){
        
                perror("open");
                exit(EXIT_FAILURE);
            }
            printf("Opened \"%s\" on fd %d\n", argv[j], fd);
    
            //并将得到的文件描述符添加到epoll 实例的兴趣列表中。将需要检查的事件集合设定为 EPOLLIN
            ev.events = EPOLLIN;            /* Only interested in input events */
            ev.data.fd = fd;
            if (epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev) == -1){
        
                perror("epoll_ctl EPOLL_CTL_ADD");
                exit(EXIT_FAILURE);
            }
        }
        numOpenFds = argc - 1;
        while (numOpenFds > 0){
        
            /* 从 epoll 实例的就绪列表中获取最多 MAX_EVENTS 项  */
            /* Fetch up to MAX_EVENTS items from the ready list of the
              epoll instance */
    
            printf("About to epoll_wait()\n");
            ready = epoll_wait(epfd, evlist, MAX_EVENTS, -1);
            if (ready == -1) {
        
                //在 epoll_wait()调用之后，程序检查是否返回了 EINTR 错误码。如果在 epoll_wait()
                //调用执行期间程序被一个信号打断，之后又通过 SIGCONT 信号恢复执行，此时就可能出现这个错误。
                if (errno == EINTR)
                    continue;               /* Restart if interrupted by signal */
                else{
        
                    perror("epoll_wait");
                    exit(EXIT_FAILURE);
                }
            }
    
            printf("Ready: %d\n", ready);
    
            /* 如果 epoll_wait()调用成功，程序就再执行一个内层循环检查 evlist 中每个已就绪的元素。*/
            for (j = 0; j < ready; j++) {
        
                printf("  fd=%d; events: %s%s%s\n", evlist[j].data.fd,
                       (evlist[j].events & EPOLLIN)  ? "EPOLLIN "  : "",
                       (evlist[j].events & EPOLLHUP) ? "EPOLLHUP " : "",   //在 FIFO 的对端关闭
                       (evlist[j].events & EPOLLERR) ? "EPOLLERR " : "");  //当终端挂起时出现
    
                if (evlist[j].events & EPOLLIN) {
          //如果返回的是 EPOLLIN，程序从对应的文件描述符中读取一些输入并在标准输出上打印出来
                    s = read(evlist[j].data.fd, buf, MAX_BUF);
                    if (s == -1){
        
                        perror("read");
                        exit(EXIT_FAILURE);
                    }
                    printf("    read %d bytes: %.*s\n", s, s, buf);
    
                } else if (evlist[j].events & (EPOLLHUP | EPOLLERR)) {
        
                    //如果返回的是 EPOLLHUP 或 EPOLLERR，程序就关闭对应的文件描述符⑩并递减打开文件数的统计量
                    /* 在 epoll_wait() 之后，EPOLLIN 和 EPOLLHUP 可能都已设置。
                     * 但如果 EPOLLIN 没有设置，我们只会到这里，从而关闭文件描述符。
                     * 这确保在关闭文件描述符之前（通过进一步的循环迭代）消耗所有未完
                     * 成的输入（可能超过 MAX_BUF 字节）。  */
    
                    printf("    closing fd %d\n", evlist[j].data.fd);
                    if (close(evlist[j].data.fd) == -1){
        
                        perror("close");
                        exit(EXIT_FAILURE);
                    }
    
                    numOpenFds--;
                }
            }
        }
    }

使用：如下用到了两个终端窗口，在其中一个窗口上用该程序来检查两个 FIFO 文件的输入。在另外一个窗口上，我们运行 cat(1)程序将数据写到这些 FIFO 中去  
![在这里插入图片描述][202106111144008.png]  
![在这里插入图片描述][20210611114405183.png]

### 文章目录 ###

*   *  创建epoll实例：epoll\_create()
     *   *  参数
         *  返回值
         *  最多能够创建多少个实例
         *  示例
     *  修改 epoll 的兴趣列表：epoll\_ctl()
     *   *  参数
         *  示例
     *  事件等待：epoll\_wait()
     *   *  参数
         *  返回值
         *  返回的条件
         *   *  1. 文件描述符状态的改变
             *   *  【对于读操作】
                 *  【对于写操作】：
             *  2. 文件描述符的事件位events置1
             *   *  【对于读操作】：
                 *  【对于写操作】：
             *  说明
     *  epoll事件
     *   *   *  EPOLLONESHOT 标志
 *  深入探究epoll的语义
 *  epoll触发模式
 *   *  水平触发(TL)
     *  边缘触发
     *   *  设置
         *  采用epoll的边缘触发通知机制的程序的基本框架
         *  当采用边缘触发通知时避免出现文件描述符饥饿现象
         *   *  什么叫做文件描述符饥饿现象
             *  解决方案
             *  水平触发有没有文件描述符饥饿现象
 *  实例
 *   *  实例1：不读出数据的ET和LT
     *   *  现象
     *  实例2：读出数据的ET和LT
     *   *  现象
     *  实例3：写数据的ET模式
     *   *  现象
     *  实例4：写数据的LT模式
 *  问题
 *   *  ET模式下的读写注意事项
     *   *  解决方法（非阻塞模式）
         *  EAGAIN
         *  上述方法中写操作的改进
     *  ET模式下的accept注意事项
     *  多路IO复用accept为什么应该工作在非阻塞模式
     *  LT模式下会不停触发socket可写事件，如何处理？
     *  epoll读到一半又有新事件来了怎么办
     *  Epoll+LT 模式下，客户端发异常报文，如何处理
     *  使用epoll时需要将socket设为非阻塞吗？【待研究】
     *  epoll 同 I/O 多路复用的性能对比
 *  实例
 *   *  例子

http://blog.chinaunix.net/uid-28541347-id-4285054.html

https://blog.csdn.net/daaikuaichuan/article/details/88777274

[b16cca5be39a4b8b9af8ab47f08e1201.png]: /images/20221005/51015e3fcfc74e4db3e29f7617b6df26.png
[665ad16e3770463cb14ad902a1e1c8e7.png]: /images/20221005/5572bdc1db494b528c6cec5692f0b221.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20221005/29bf75210a56470dbecca2d73d77720f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]: /images/20221005/f68056d457a54f848fb69614ac0e6fdd.png
[7c7a2984a9c141c68d81aef9f6eac41b.png]: /images/20221005/21eece2d2fc040209fe8b6037ad5fe29.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]: /images/20221005/d8cffebe74df428887eda61dea1bf60a.png
[3514daf8b80d44699dc65dc664674ac9.png]: /images/20221005/d5b9ec89963848eb96a0d537e33e6ad6.png
[df9dad1f49f649f38f0c6ab3df236499.png]: /images/20221005/51ed47217b584b1187e8813c7c36a511.png
[37e23565b4684faea075f3856a617948.png]: /images/20221005/a291d3171e7b4199a8da32629dfb846f.png
[6b5d1233ee284719a4b50e07939d615e.png]: /images/20221005/eecfb584154c4a47bc78140470ebe3cd.png
[Link 1]: https://www.zhihu.com/question/365479182
[Link 2]: https://www.zhihu.com/question/23614342
[202106111144008.png]: /images/20221005/98e080f3b2914dadaa7371e125d44734.png
[20210611114405183.png]: /images/20221005/87973a65f23b4795a07eb4387fb43d46.png