Libev源码分析—常用watcher

左手的ㄟ右手 2022-08-09 06:26 242阅读 0赞

**Libev源码分析—常用watcher**

在上一篇文章里，我们分析了libev整体设计思想和主循环的工作原理，也提到了watcher是衔接开发者代码的主要入口。watcher与开发者最接近，也与具体事件处理逻辑最接近。所以，watcher的具体实现，与性能的关系也相当密切。下面，我们就来分析一下，libev中常用的几种watcher的设计与实现。

# ev\_io #

## ev\_io与底层io ##

ev\_io的主要使命就是监听并响应指定文件描述fd上的读写事件。对fd的监听工作，主要委托给底层的io库来完成。libev对目前比较流行的io库都提供了支持，如：select, epoll以及windows的iocp等。在这里libev使用了Adaptor模式，通过统一的适配层隐藏了底层io库的细节。在loop初始化的时候（loop\_init），会根据配置将函数指针绑定到底层的io库函数对应的适配代码上。所以，开发者可以很方便的把代码切换到不同的底层实现上。相关的函数有：backend\_modify，向底层库注册fd事件，如：epoll的epoll\_ctl；backend\_poll，向底层库轮询fd上是否有感兴趣的事件发生，如：epoll的epoll\_wait。适配器实现的代码可以在ev\_LIB.c中看到，LIB是io库的名字，如：ev\_epoll.c，ev\_win32.c等。

![ev\_io层次结构图][ev_io]

## ev\_io的结构 ##

<table style="margin:0px; padding:0px; border:0px; font-style:inherit; font-variant:inherit; font-weight:inherit; line-height:inherit; font-family:inherit; font-size:16px; vertical-align:baseline; border-collapse:collapse; border-spacing:0px"> 
 <tbody style="margin:0px; padding:0px; border:0px; font-style:inherit; font-variant:inherit; font-weight:inherit; line-height:inherit; font-family:inherit; vertical-align:baseline"> 
 <tr style="margin:0px; padding:0px; border:0px; font-style:inherit; font-variant:inherit; font-weight:inherit; line-height:inherit; font-family:inherit; vertical-align:baseline"> 
 <td style="margin:0px; padding:0px; border:0px; font-style:inherit; font-variant:inherit; line-height:inherit; font-family:inherit; font-size:16px; vertical-align:middle"> <pre style="margin-top:0px; margin-bottom:0px; border-top-style:none; border-bottom-style:none; border-left-style:none; font-style:inherit; font-variant:inherit; font-weight:inherit; line-height:1.45em; font-family:Menlo,Monaco,'Andale Mono','lucida console','Courier New',monospace; font-size:13px; vertical-align:baseline; overflow:auto; text-align:right; padding:0.8em!important; border-right-width:1px!important; border-right-style:solid!important; border-right-color:rgb(0,35,44)!important">1
2
3
4
5
6
7
</pre> </td> 
 <td style="margin:0px; padding:0px; border:0px; font-style:inherit; font-variant:inherit; line-height:inherit; font-family:inherit; font-size:16px; vertical-align:middle; width:608px"> <pre style="margin-top:0px; margin-bottom:0px; padding:0px; border:none; font-style:inherit; font-variant:inherit; font-weight:inherit; line-height:1.45em; font-family:Menlo,Monaco,'Andale Mono','lucida console','Courier New',monospace; font-size:13px; vertical-align:baseline; overflow:auto"><code style="margin:0px; border:0px; font-style:inherit; font-variant:inherit; font-weight:inherit; line-height:1.45em; vertical-align:baseline; overflow-y:hidden; display:block; overflow-x:auto; padding:0.8em!important; font-family:Menlo,Monaco,'Andale Mono','lucida console','Courier New',monospace!important">typedef struct ev_io { EV_WATCHER_LIST (ev_io) int fd; /* ro */ int events; /* ro */ } ev_io; </code></pre> </td> 
 </tr> 
 </tbody> 
</table>

其中，EV\_WATCHER\_LIST是EV\_WATCHER结构的链表节点结构。fd是监听的文件描述符，events是感兴趣的事件。 ev\_io从它诞生的那一刻起，便于文件描述符紧密结合在一起了。ev\_io的实例被存储在loop->anfds的结构中。anfds的结构如下图所示：

![anfds结构图][anfds]

anfds其实是一个数组，它使用fd作为下标，数组中的元素是一个ANFD的结构。ANFD是一个维护fd信息的结构体。其中，events记录了当前fd上感兴趣的事件的记录。head是watcher列表的头指针，这个列表就是在这个fd上注册的watcher列表。当fd的大小超出了anfds的容量，anfds会进行相应的扩展。

anfds可以理解成一个简易的map，记录了fd与ANFD结构的映射关系。虽然，fd的申请和释放操作会导致fd不一定是连续的，从而导致数组中出现空洞，但通过fd可以迅速获取到相应的watcher列表，这也许是用空间换取时间的一个考量吧。另一方面，因为fd的释放操作并不会发出通知，而系统分配fd总是采用可用的最小fd。所以如果一个fd在别处被释放，这个fd则很有可能被分配给随后打开的其他文件。而libev对这个过程是完全不知情的，所以它会傻傻的一直认为这个fd一直指向同一个文件，默默地服务着上面发生的事件。libev不负责管理fd的改变行为，而是把这个任务交给了外面，也就是说，如果外面fd发生了改变，需要调用ev\_io\_set或ev\_io\_init来重新设定fd与watcher的关系。

## ev\_io的插入 ##

从前面的介绍我们知道，要通过libev来监听fd上的事件，得要先插入一个ev\_io到libev的loop中。ev\_io的插入操作被封装在ev\_io\_start函数中。毫无疑问，libev首先会根据fd找到对应的watcher列表，并将新watcher加入到列表中。接下来，会调用fd\_change函数，将fd加入到loop->fdchanges中。fdchanges是一个简单的数组，记录的是当前注册事件有发生改变的fd。到此为止，新ev\_io的插入完成，上面的所有操作时间代价都是O(1)。fdchanges的作用在下一个小节中进行分析。

## ev\_io的选取 ##

前面我们已经向libev的loop中插入了一个ev\_io，那么libev是怎么把这个ev\_io注册到底层io并响应底层的io事件的呢？ 要回答这个问题，我们得先回到之前写的一篇博文[libev整体分析][libev]。从ev\_run流程图中可以看到，ev\_io的选取由fd\_reify和backend\_poll这两个步骤来完成。

fd\_reify函数的工作主要是遍历fdchanges，将对应列表的watcher的events字段合并到ANFD结构的events字段。ANFD上如果新的events与原来监听的events不一致，则表示在这个fd上监听的事件集发生了变化，需要将fd和事件集合通过backend\_modify注册到底层的io库。

在循环的后面，则会调用backend\_poll来检查fd上是否有注册的事件发生。如果有事件发生，则通过fd\_event函数，遍历fd对应的watcher列表，比较每个watcher上的events字段与发生的事件event值，找出就绪的watcher添加到pendings中。

最后，这些pendings中的watcher会在循环结束前调用ev\_invoke\_pending来统一触发。

## ev\_io的移除 ##

ev\_io的移除由ev\_io\_stop来完成。首先，会先检查该watcher是否在pendings列表中，如果是，则先从pendings中删除该watcher。pendings是一个数组，libev中的数组一般是以数组和元素数量来维护的。删除数组中的一个元素，只要把数组末尾的元素替换掉被删除的元素，并把元素数量减一就可以了，操作的时间复杂度是O(1) 。

接下来就是通过fd找到watcher列表，从中删除这个watcher。这个操作需要遍历列表找到待删除的watcher，所以平均时间复杂度是O(n)。其中n是注册在fd上的watcher数量，一般这个数量不会太大。

然后是把watcher的active标志位复位，并减少全局active的watcher计数。

最后是把fd加入到fdchanges中，因为移除一个watcher，可能会改变fd上感兴趣的事件，所以要在下一轮循环中重新计算该fd上的事件集合。

# ev\_timer #

## ev\_timer的管理 ##

ev\_timer watcher是主要负责处理超时事件的watcher。这类watcher被存储在loop->timers中，它们的特点是，超时时间小的watcher会被先触发。所以，timers其实是一个按触发时间升序排序的优先队列，底层的数据结构是一个用数组实现的二叉或四叉最小堆（关于堆的定义请google之）。ev\_timer watcher的active字段，维护的其实是watcher在堆中的下标，通过它可以快速在堆中定位到watcher。

堆相关基本的堆操作有upheap和downheap。upheap操作是将一个节点上移到堆中合适的位置；downheap操作则刚好相反，将一个节点下移到堆中合适的位置。最小堆的特点是父节点的值比子节点的值都要小。通过这两个操作，可以调整堆中节点的位置，以满足最小堆的约束。它们的时间复杂度都是O(log(n))。有了这两个操作，便可以构建出watcher结构的常用操作了。

*  获取超时的watcher。因为timers是一个以触发时间排序的最小堆，根部的watcher总是最先要触发的watcher。所以这个操作的主要工作就是比较根部watcher的触发时间，如果可以触发，则加入pendings队列。然后检查该watcher是否是repeat的。如果是则更新下一次触发时间，调用downheap操作将这个节点下移至合适的位置；否则直接删除该watcher。
 *  添加新的watcher。这无非就是一个入堆的操作。将新watcher添加到timers数组的末尾，再执行upheap操作，上升至合适的位置即可。
 *  删除watcher。将堆尾节点替换掉待删除节点，再根据情况用upheap或downheap操作来调整替换后节点到合适的位置。

以上这些操作的时间代价都是O(log(n))。

## timer的使用策略 ##

在实际应用中，可能会出现频繁使用大量timer的场景。比如：为每个请求设置一个超时时间，在指定时间内得不到响应，则报错。如果为每一个请求创建一个watcher，则将产生大量不必要的空间和计算开销。在libev的官方文档中，提供了一个比较高效的[方法][Link 1]。下面简单介绍一下这种方法的思路。

可以使用一个双向链表来维护超时时间相同的timer，这里的timer可以理解为定时器的记录结构，比如：超时时间和超时的回调函数等。因为大家的超时时间是一样的，所以新的timer进来后，肯定是添加到队尾的。

然后分配一个ev\_timer watcher专门来处理这个链表的超时工作。watcher的超时时间设置的是链表第一个元素的超时时间。当超时发生后，按链表顺序触发超时的timer。如果timer是重复的，可以重新计算超时时间并加入到链表尾部；否则直接删除timer记录即可。然后再从链表首部获取下一次超时时间，重复上面的流程。

采用这种方案，只需要使用一个ev\_timer watcher来处理相同timeout时间的timer。而timer的增删操作最后其实就是链表的插入和删除操作，所以操作的时间代价都是O(1)。而timeout时间相同的约束，主要是要保证链表里的元素都是有序的，插入操作都是发生在链表的尾端。如果要取消某一个timer，因为是双向链表，也可以在O(1)时间内从链表内移除掉指定的节点。

# ev\_prepare, ev\_check, ev\_idle #

从角色上来看，这三个类型的watcher其实都是事件循环的一个扩展点。通过这三个watcher，开发者可以在事件循环的一些特殊时刻获得回调的机会。

*  ev\_prepare 在事件循环发生阻塞前会被触发。
 *  ev\_check 在事件循环阻塞结束后会被触发。ev\_check的触发是按优先级划分的。可以保证，ev\_check是同一个优先级上阻塞结束后最先被触发的watcher。所以，如果要保证ev\_check是最先被执行的，可以把它的优先级设成最高。
 *  ev\_idle 当没有其他watcher被触发时被触发。ev\_idle也是按优先级划分的。它的语义是，在当前优先级以及更高的优先级上没有watcher被触发，那么它就会被触发，无论之后在较低优先级上是否有其他watcher被触发。

这三类watcher给外部的开发者提供了非常便利的扩展机制，在这个基础上，开发者可以做很多有意思的事情，也对事件循环有了更多的控制权。具体到底能做些什么，做到什么程度，那就要看开发者们的想象力和创造力了：）

# 总结 #

ev\_io和ev\_timer应该是libev中使用的最多的watcher了，也是比较典型的watcher。从底层的实现上来看，处理得恰到好处，精明而干练，可谓独具匠心.

[ev_io]: /images/20220731/87146d024c4f48f295368820c7cb8ff5.png
[anfds]: /images/20220731/2804aa5ec9144dbebc893e2b12b009e0.png
[libev]: http://blog.csdn.net/chdhust/article/details/38924997
[Link 1]: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#Be_smart_about_timeouts