关于io:高级IO模型之kqueue和epoll

44次阅读

共计 3231 个字符,预计需要花费 9 分钟才能阅读完成。

简介

任何一个程序都离不开 IO,有些是很显著的 IO,比方文件的读写,也有一些是不显著的 IO, 比方网络数据的传输等。那么这些 IO 都有那些模式呢?咱们在应用中应该如何抉择呢?高级的 IO 模型 kqueue 和 epoll 是怎么工作的呢?一起来看看吧。

block IO 和 nonblocking IO

大家先来理解一下 IO 模型中最简略的两个模型: 阻塞 IO 和非阻塞 IO。

比方咱们有多个线程要从一个 Socket server 中读取数据,那么这个读取过程其实能够分成两个局部,第一局部是期待 socket 的数据筹备结束,第二局部是读取对应的数据进行业务解决。对于阻塞 IO 来说,它的工作流程是这样的:

  1. 一个线程期待 socket 通道数据筹备结束。
  2. 当数据筹备结束之后,线程进行程序处理。
  3. 其余线程期待第一个线程完结之后,持续上述流程。

为什么叫做阻塞 IO 呢?这是因为当一个线程正在执行的过程中,其余线程只能期待, 也就是说这个 IO 被阻塞了。

什么叫做非阻塞 IO 呢?

还是下面的例子,如果在非阻塞 IO 中它的工作流程是这样的:

  1. 一个线程尝试读取 socket 的数据。
  2. 如果 socket 中数据没有筹备好,那么立刻返回。
  3. 线程持续尝试读取 socket 的数据。
  4. 如果 socket 中的数据筹备好了,那么这个线程继续执行后续的程序处理步骤。

为什么叫做非阻塞 IO 呢?这是因为线程如果查问到 socket 没有数据,就会立即返回。并不会将这个 socket 的 IO 操作阻塞。

从下面的剖析能够看到,尽管非阻塞 IO 不会阻塞 Socket,然而因为它会始终轮询 Socket,所以并不会开释 Socket。

IO 多路复用和 select

IO 多路复用有很多种模型,select 是最为常见的一种。实时不论是 netty 还是 JAVA 的 NIO 应用的都是 select 模型。

select 模型是怎么工作的呢?

事实上 select 模型和非阻塞 IO 有点类似,不同的是 select 模型中有一个独自的线程专门用来查看 socket 中的数据是否就绪。如果发现数据曾经就绪,select 能够通过之前注册的事件处理器,抉择告诉具体的某一个数据处理线程。

这样的益处是尽管 select 这个线程自身是阻塞的,然而其余用来真正解决数据的线程却是非阻塞的。并且一个 select 线程其实能够用来监控多个 socket 连贯,从而进步了 IO 的解决效率,因而 select 模型被利用在多个场合中。

为了更加具体的理解 select 的原理,咱们来看一下 unix 下的 select 办法:

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *errorfds, struct timeval *timeout);

先来解释一下这几个参数的含意,咱们晓得 unix 零碎中,所有的对象都是文件,所以这里的 fd 示意的就是 file descriptor , 也就是文件描述符。

fds 示意的是 file descriptor sets,也就是文件描述符汇合。

nfds 是一个整数值,示意的是文件描述符汇合中最大值 +1.

readfds 是要查看的文件读取的描述符汇合。

writefds 是要查看的文件写入的描述符汇合。

errorfds 是要查看的文件异样描述符汇合。

timeout 是超时工夫,示意的是期待抉择实现的最大距离。

其工作原理是轮询所有的 file descriptors, 而后找到要监控的那些文件描述符,

poll

poll 和 select 类很相似,只是形容 fd 汇合的形式不同. poll 次要是用在 POSIX 零碎中。

epoll

实时上,select 和 poll 尽管都是多路复用 IO,然而他们都有些毛病。而 epoll 和 kqueue 就是对他们的优化。

epoll 是 linux 零碎中的系统命令,能够将其看做是 event poll。首次是在 linux 外围的 2.5.44 版本引入的。

次要用来监控多个 file descriptors 其中的 IO 是否 ready。

对于传统的 select 和 poll 来说,因为须要一直的遍历所有的 file descriptors,所以每一次的 select 的执行效率是 O(n) , 然而对于 epoll 来说,这个工夫能够晋升到 O(1)。

这是因为 epoll 会在具体的监控事件产生的时候触发告诉,所以不须要应用像 select 这样的轮询,其效率会更高。

epoll 应用红黑树 (RB-tree) 数据结构来跟踪以后正在监督的所有文件描述符。

epoll 有三个 api 函数:

int epoll_create1(int flags);

用来创立一个 epoll 对象,并且返回它的 file descriptor。传入的 flags 能够用来管制 epoll 的体现。

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

这个办法用来对 epoll 进行管制,能够用来监控具体哪些 file descriptor 和哪些事件。

这里的 op 能够是 ADD, MODIFY 或者 DELETE。

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

epoll_wait 用来监听应用 epoll_ctl 办法注册的事件。

epoll 提供了两种触发模式,别离是 edge-triggered 和 level-triggered。

如果一个应用 epoll 注册的 pipe 收到了数据,那么调用 epoll_wait 将会返回,示意存在要读取的数据。然而在 level-triggered 模式下,只有管道的缓冲区蕴含要读取的数据,对 epoll_wait 的调用将立刻返回。然而在 level-triggered 模式下,epoll_wait 只会在新数据写入管道后返回。

kqueue

kqueue 和 epoll 一样,都是用来替换 select 和 poll 的。不同的是 kqueue 被用在 FreeBSD,NetBSD, OpenBSD, DragonFly BSD, 和 macOS 中。

kqueue 不仅可能解决文件描述符事件,还能够用于各种其余告诉,例如文件批改监督、信号、异步 I/O 事件 (AIO)、子过程状态更改监督和反对纳秒级分辨率的计时器,此外 kqueue 提供了一种形式除了内核提供的事件之外,还能够应用用户定义的事件。

kqueue 提供了两个 API,第一个是构建 kqueue:

int kqueue(void);

第二个是创立 kevent:

int kevent(int kq, const struct kevent *changelist, int nchanges, struct kevent *eventlist, int nevents, const struct timespec *timeout);

kevent 中的第一个参数是要注册的 kqueue,changelist 是要监督的事件列表,nchanges 示意要监听事件的长度,eventlist 是 kevent 返回的事件列表,nevents 示意要返回事件列表的长度,最初一个参数是 timeout。

除此之外,kqueue 还有一个用来初始化 kevent 构造体的 EV_SET 宏:

EV_SET(&kev, ident, filter, flags, fflags, data, udata);

epoll 和 kqueue 的劣势

epoll 和 kqueue 之所以比 select 和 poll 更加高级,是因为他们充分利用操作系统底层的性能,对于操作系统来说,数据什么时候 ready 是必定晓得的,通过向操作系统注册对应的事件,能够防止 select 的轮询操作,晋升操作效率。

要留神的是,epoll 和 kqueue 须要底层操作系统的反对, 在应用的时候肯定要留神对应的 native libraries 反对。

本文已收录于 http://www.flydean.com/14-kqueue-epoll/

最艰深的解读,最粗浅的干货,最简洁的教程,泛滥你不晓得的小技巧等你来发现!

欢送关注我的公众号:「程序那些事」, 懂技术,更懂你!

正文完
 0