libevent研究ノート

機能フローチャートevent_base_loop

event_base_loop（）関数によって主にLibeventメインイベントループは以下のフローチャートに示すメイン動作として実現される、event_base_loopは、連続的に次のサイクルを実行されています。

int型 event_base_loop（構造体 event_base * ベース、int型のフラグ）
{
constの 構造体 eventop EVSEL = * ベース - > EVSEL; // IOが多重
ストラクト体timevalテレビ、
 構造体体timevalを* tv_p;
 int型の RES、DONE、RETVAL = 0 ;
EVBASE_ACQUIRE_LOCK(base, th_base_lock);
if (base->running_loop) {//检测event_base_loop是否已经运行，每个event_base只有一个event_base_loop
event_warnx("%s: reentrant invocation. Only one event_base_loop"
" can run on each event_base at once.", __func__);
EVBASE_RELEASE_LOCK(base, th_base_lock);
return -1;
}
base->running_loop = 1;
clear_time_cache(base);//清空时间缓存
if (base->sig.ev_signal_added && base->sig.ev_n_signals_added)
evsig_set_base(base);// evsignal_base是全局变量，在处理signal时，用于指名signal所属的event_base实例
done = 0;
#ifndef _EVENT_DISABLE_THREAD_SUPPORT
base->th_owner_id = EVTHREAD_GET_ID();
#endif
base->event_gotterm = base->event_break = 0;
while (!done) {// 事件主循环
base->event_continue = 0;
if (base->event_gotterm) {
break;// 查看是否需要跳出循环，程序可以调用event_loopexit_cb()设置event_gotterm标记
}
if (base->event_break) {
break;// 调用event_base_loopbreak()设置event_break标记
}
// 校正系统时间，如果系统使用的是非MONOTONIC时间，用户可能会向后调整了系统时间
// 在timeout_correct函数里，比较last wait time和当前时间，如果当前时间< last wait time
// 表明时间有问题，这是需要更新timer_heap中所有定时事件的超时时间。
timeout_correct(base, &tv);
// 根据timer heap中事件的最小超时时间，计算系统I/O demultiplexer的最大等待时间
tv_p = &tv;
if (!N_ACTIVE_CALLBACKS(base) && !(flags & EVLOOP_NONBLOCK)) {
timeout_next(base, &tv_p);
} else {
evutil_timerclear(&tv);
}
// 如果当前没有注册事件，就退出
if (!event_haveevents(base) && !N_ACTIVE_CALLBACKS(base)) {
event_debug(("%s: no events registered.", __func__));
retval = 1;
goto done;
}
gettime(base, &base->event_tv);
clear_time_cache(base);
// 调用系统I/O demultiplexer等待就绪I/O events，可能是epoll_wait，或者select等；
// 在evsel->dispatch()中，会把就绪signal event、I/O event插入到激活链表中
res = evsel->dispatch(base, tv_p);
if (res == -1) {
event_debug(("%s: dispatch returned unsuccessfully.",
__func__));
retval = -1;
goto done;
}
update_time_cache(base);
timeout_process(base);
// 调用event_process_active()处理激活链表中的就绪event，调用其回调函数执行事件处理
// 该函数会寻找最高优先级（priority值越小优先级越高）的激活事件链表，
// 然后处理链表中的所有就绪事件；
// 因此低优先级的就绪事件可能得不到及时处理；
if (N_ACTIVE_CALLBACKS(base)) {
int n = event_process_active(base);
if ((flags & EVLOOP_ONCE)
&& N_ACTIVE_CALLBACKS(base) == 0
&& n != 0)
done = 1;
} else if (flags & EVLOOP_NONBLOCK)
done = 1;
}
event_debug(("%s: asked to terminate loop.", __func__));
done:
clear_time_cache(base);
base->running_loop = 0;
EVBASE_RELEASE_LOCK(base, th_base_lock);
return (retval);
}

I/O和Timer事件的统一

Libevent将Timer和Signal事件都统一到了系统的I/O 的demultiplex机制中了，相信读者从上面的流程和代码中也能窥出一斑了，下面就再啰嗦一次了。

首先将Timer事件融合到系统I/O多路复用机制中，还是相当清晰的，因为系统的I/O机制像select()和 epoll_wait()都允许程序制定一个最大等待时间（也称为最大超时时间）timeout，即使没有I/O事件发生，它们也保证能在timeout时间内返回。

那么根据所有Timer事件的最小超时时间来设置系统I/O的timeout时间；当系统I/O返回时，再激活所有就绪的Timer事件就可以了，这样就能将Timer事件完美的融合到系统的I/O机制中了。

这是在Reactor和Proactor模式（主动器模式，比如Windows上的IOCP）中处理Timer事件的经典方法了，ACE采用的也是这种方法，大家可以参考POSA vol2书中的Reactor模式一节。

堆是一种经典的数据结构，向堆中插入、删除元素时间复杂度都是O(lgN)，N为堆中元素的个数，而获取最小key值（小根堆）的复杂度为O(1)；因此变成了管理Timer事件的绝佳人选（当然是非唯一的），libevent就是采用的堆结构。

I/O和Signal事件的统一

Signal是异步事件的经典事例，将Signal事件统一到系统的I/O多路复用中就不像Timer事件那么自然了，Signal事件的出现对于进程来讲是完全随机的，进程不能只是测试一个变量来判别是否发生了一个信号，而是必须告诉 “内核“在此信号发生时，请执行如下的操作”。

如果当Signal发生时，并不立即调用event的callback函数处理信号，而是设法通知系统的I/O机制，让其返回，然后再统一和I/O事件以及Timer一起处理，不就可以了嘛。是的，这也是libevent中使用的方法。

问题的核心在于，当Signal发生时，如何通知系统的I/O多路复用机制，比如使用pipe。

from ： Libevent学习

機能フローチャートevent_base_loop

I/O和Timer事件的统一

I/O和Signal事件的统一

おすすめ