epoll使用详解

进程级的描述符表的每一条目记录了单个文件描述符的相关信息。

1. 控制文件描述符 *** 作的一组标志。（目前，此类标志仅定义了一个，即close-on-exec标志）

2. 对打开文件句柄的引用

内核对所有打开的文件的文件维护有一个系统级的描述符表格（open file description table）。有时，也称之为打开文件表（open file table），并将表格中各条目称为打开文件句柄（open file handle）。一个打开文件句柄存储了与一个打开文件相关的全部信息，如下所示：

1. 当前文件偏移量（调用read()和write()时更新，或使用lseek()直接修改）

2. 打开文件时所使用的状态标识（即，open()的flags参数）

3. 文件访问模式（如调用open()时所设置的只读模式、只写模式或读写模式）

4. 与信号驱动相关的设置

5. 对该文件i-node对象的引用

6. 文件类型（例如：常规文件、套接字或FIFO）和访问权限

7. 一个指针，指向该文件所持有的锁列表

8. 文件的各种属性，包括文件大小以及与不同类型 *** 作相关的时间戳

下图展示了文件描述符、打开的文件句柄以及i-node之间的关系，图中，两个进程拥有诸多打开的文件描述符。

Epoll - I/O event notification facility

翻译一下，epoll是一种I/O事件通知机制，这句话基本上包含了所有需要理解的要点：

epoll是一种当文件描述符的内核缓冲区非空的时候，发出可读信号进行通知，当写缓冲区不满的时候，发出可写信号通知的机制

epoll的接口非常简单，一共就三个函数：

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

EPOLLIN ：表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；

EPOLLOUT：表示对应的文件描述符可以写；

EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；

EPOLLERR：表示对应的文件描述符发生错误；

EPOLLHUP：表示对应的文件描述符被挂断；

EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。

EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里

首先通过 create_epoll(int maxfds) 来创建一个epoll的句柄，其中 maxfds 为你epoll所支持的最大句柄数。这个函数会返回一个新的epoll句柄，之后的所有答派 *** 作将通过这个句柄来进行 *** 作。在用完之后，记得用 close() 来关闭这个创建出来的epoll句柄。

之后在你的网络主循环里面，每一帧的调用逗芹 epoll_wait(int epfd, epoll_event events, int max events, int timeout) 来查询所有的网络接口，看哪一个可以读，哪一个可以写了。基本的语法为：

nfds = epoll_wait(kdpfd, events, maxevents, -1)

其中kdpfd为用 epoll_create 创建之后的句柄，events是一个 epoll_event* 的指针，当 epoll_wait 这个函数 *** 作成功之后， epoll_events 里面将储存所有的读写事件。 max_events 是当前需要监听的所有 socket 句柄数。 最后一个 timeout 是 epoll_wait 的超时，为0的时候表示马上返回，为-1的时候表示一直等下山举毕去，直到有事件范围，为任意正整数的时候表示等这么长的时间，如果一直没有事件，则范围。 一般如果网络主循环是单独的线程的话，可以用-1来等，这样可以保证一些效率，如果是和主逻辑在同一个线程的话，则可以用0来保证主循环的效率。

epoll_wait范围之后应该是一个循环，遍利所有的事件。

几乎所有的epoll程序都使用下面的框架：

下面给出一个完整的服务器端例子：

EPOLL 的API用来执行类似poll()的任务。能够用于检测在多个文件描述符中任何IO可用的情况。Epoll API可以用于边缘触发(edge-triggered)和水平触发(level-triggered), 同时epoll可以检测更多的文件描述符。以下的系统调用函数提供了创建和管理epoll实例：

边缘触发(edge-triggered 简称ET)和水平触发(level-triggered 简称LT)：

epoll的事件派发接口可以运行在两种模式下：边缘触发(edge-triggered)和水平触发(level-triggered)，两种模式的区别请看下面,我们先假设下面的情况：

如果rfd被设置了ET，在调用完第五步的epool_wait 后会被挂起，尽管在缓冲区还有可以读取的数据，同时另外一段的管道还在等待发送完毕的反馈。这是因为ET模式下只有文件描述符发生改变的时候，才会派发事件。所以第五步 *** 作，可能会去等待已经存在缓冲区的数据。在上面的例子中，一个事件在第二步被创建，再第三步中被消耗，由于第四步中没有读取完缓冲区，第五步中的epoll_wait可能会一直被阻塞下去。

下面情况下推荐使用ET模式:

相比之下，当我们使用LT的时候（默认）,epoll会比poll更简单更快速，而且我们可以使用在任何一个地方。

先简单的看下EPOLL的API

epoll_create() 可以创建一个epoll实例。在linux 内核版本大于2.6.8 后，这个 size 参数就被弃用了，但是传入的值必须大于0。

epoll_create() 会返回新的epoll对象的文件描述符。这个文件描述符用于后续的epoll *** 作。如果不需要使用这个描述符，请使用close关闭。

epoll_create1() 如果 flags 的值是0，epoll_create1()等同于epoll_create()除了过时的size被遗弃了。当然 flasg 可以使用 EPOLL_CLOEXEC，请查看 open() 中的O_CLOEXEC来查看 EPOLL_CLOEXEC有什么用。

返回值: 如果执行成功，返回一个非负数(实际为文件描述符), 如果执行失败，会返回-1，具体原因请信锋带查看error.

这个系统调用能够控制给定的文件描述符 epfd 指向的epoll实例， op 是添加事件的类型， fd 是目标文件描滑芦述符。

有效的op值有以下几种：

event 这个参数是用于关联制定的 fd 文件描述符的。它的定义如下：

events 这个参数是一个字节的掩码构成的。下面是可以用的事件：

返回值： 如果成功，返回0。如果失败，会返回-1， errno 将会被设置

有以下几种错误：

epoll_wait 这个系统调用是用来等待 epfd 中的事件。 events 指向调用者可以使用的事件的内存区域。 maxevents 告知内核有多少个events，必须要大于0.

timeout 这个参数是用来制定epoll_wait 会阻塞多少毫秒，会一直阻塞到下面几种情况：

当 timeout 等于-1的时候这个函数会无限期的阻塞下去，当 timeout 等于0的时候，就算没有任何事件，也会立刻返回。

struct epoll_event 如下定义:

每次epoll_wait() 返回的时候，会包含用户在epoll_ctl中设置的events。

还有一个系统调用epoll_pwait ()。epoll_pwait()和epoll_wait ()的关系就像select()和 pselect()的关系。和pselect()一样，epoll_pwait()可以让应用程序安全的等待知道某一个文件描述符就绪或者捕捉到信号。

下面的 epoll_pwait () 调用：

在内部等同于:

如果 sigmask 为NULL, epoll_pwait()等同于epoll_wait()。

返回值： 有多少个IO事件已经准备就绪基穗。如果返回0说明没有IO事件就绪，而是timeout超时。遇到错误的时候，会返回-1，并设置 errno。

有以下几种错误:

    我们都知道Node.js是异步的，那么Node.js为什么会是异步的呢？这是因为Node.js使用了LIBUV做为它的跨平台抽象层。具体请看 nodejs运行机制

    select、poll、epoll是Linux平台下的IO多路复用机制，用来管理大量的文件描述符。但是select/poll相对于epoll来说效率是低下的。

   源友档   1、linux内核在select的每次返回前都要对所有的描述符 循环遍历 ，将有事件发生的文件描述符放在一个集合里返回。在描述符不多的时候对性能影响不大，但是当描述符达到数十万甚至更多的时候，这种处理方式造成大量的浪费和资源开销，select的效率会急剧下降。这是因为每次select的时候，会将所有的文件描述符从用户态拷贝的内核态，在内核态进行循环，查看是否有事件发生。2、select默认的管理的最大文件描述符是1024个，当然可以对linux内核从新编译来改变这个限制。

    原理和select相似也是使用循环遍历的方式管理文件描述符，不同的是管理的文件最大文件描述符的数量没有限制（根据系统限制来定）。

下文讲解epoll实现原理

    epoll改进了select的两个缺点，从而能够在管理大量的描述符的情况下，对系统资源的使用并没有急剧的增加，而只是对内存的使用有所增加（毕竟存储大量的描述雹乱符的数据结构会占用大量内存）。epoll在实现上的三个核心点是：1、mmap，2、红黑树，3、rdlist(就绪描述符链表)接下来一一解释这三个并且解释为什么会高效。

    mmap是共享内存，用户进程和内核有一段地址(虚拟存储器地址)映射到了同一块物理地址上，这样当内核要对描述符上的事件进行检查的时候就不用来回的拷贝了。   

    红黑树是用来存储这些描述符的。当内核初始化epoll的时候（当调用epoll_create的时候内核也是个epoll描述符创建了一个文件，毕竟在Linux中一切都是文件，而epoll面对的是一个特殊的文件，和普通文件不同），会开辟出一块内核缓冲区，这块区域用来存储我们要监管的所有的socket描述符，当然在这里面存储有一个数据结构，这就是红黑树，由于红黑树的接近平衡的查找，插入，删除能力，在这里显著的提高了对描述符的管理。

        rdlist就绪描述符链表这是一个双链表，epoll_wait()函数返回的也是这个就绪链表。当内核创建了红黑树之后，同时也会建立一个双向链表rdlist，用于存储准备就绪的描述符，当调用epoll_wait的时候在timeout时间内，只是简单的去管理这个rdlist中是否有数据，如果没有则睡眠至超时，如果有数据则立即返回并将链表中的数据赋值到events数组中。这样就能够高效的管理就绪的描述符，而不用去轮询所有的描述符。

        当执行epoll_ctl时除了把socket描述符放入到红黑树中之外，还会给内核中断处理程序注册一个回调函数，告诉内核，当这个描述符上有事件到达（或者说中断了）的时候就调用这个回调函数。这个回调函数的作用就是将描述符放入到rdlist中，所以当一个socket上的数据到达的时候内核就会把网卡上的数据复制到内核，然后把socket描述符插入就绪链表rdlist中。

Epoll的两种模式：

      1. 水平触发（LT）：使用此种模式，当数据可读的时候，epoll_wait()将会一直返回就绪事件。如果你没有处理完全部数据，并且再次在该epoll实例上调用epoll_wait()才监听描述符的时候，它将会再次返回就绪事件，因为有数据可读。告雹

      2. 边缘触发（ET）：使用此种模式，只能获取一次就绪通知，如果没有处理完全部数据，并且再次调用epoll_wait()的时候，它将会阻塞，因为就绪事件已经释放出来了。

        ET的效能更高，但是对程序员的要求也更高。在ET模式下，我们必须一次干净而彻底地处理完所有事件。

epoll的linux实现

---