libevent 结构分析
libevent是一个针对*nix的高级IO的库（FreeBSD:kqueue, Linux:epoll, Solaris:/dev/poll）的封装（虽然对于windows它也能工作，不过它封装的不是iocp，所以这里就不讨论了）。现在我们看看 libevent的实现结构。
1、libevent使用的数据结构简介
libevent中使用了tail queue、red black tree，现在简单总结一下，免得我自己忘了。
1、tail queue:
它的基本特性和单向链表一样，但是在它的head中增加了一个指向末尾的指针，所以它能够直接在链表的尾部插入数据，但是它所付出的代价是：
它实现的代码量要比同算法的单向链表增加15%,而且运行效率上要增加约20%的开销。
现在先看一个例子(以下代码只为了说明tail queue的使用，不考虑错误)；
TAILQ_HEAD(my_tq, entry) head;
//just for show
struct my_tq *my_head;
struct entry {
...
TAILQ_ENTRY(entry) entry_tq;
...
};
my_head = malloc(sizeof(my_tq));
TAILQ_INIT(my_head);
TAILQ_INSERT_HEAD(my_head, p1 = malloc(sizeof(struct entry)), entry_tq);
TAILQ_INSERT_TAIL(my_head, p2 = malloc(sizeof(struct entry)), entry_tq);
TAILQ_INSERT_AFTER(my_head, p2, malloc(sizeof(struct entry)), entry_tq);
while (my_head->tqh_first != NULL)
TAILQ_REMOVE(my_head, my_head->tqh_first, entry_tq);
tail queue的操作相关宏：
TAILQ_HEAD(HEADNAME, TYPE) head --->定义串连TYPE类型的结构，同时将这种"新"类型的tail queue结构命名为HEADNAME, 最后还定义了一个变量“head”。
TAILQ_INIT(&head) --->初始化tail queue的两个指针，对列的头指针和队列的尾指针
TAILQ_ENTRY (TYPE) --->这个宏使用在TYPE结构体的定义内部，它定义维护结构体对象在tail queue中的位置所需要的指针。
TAILQ_INSERT_HEAD/TAILQ_INSERT_TAIL/TAILQ_INSERT_AFTER/TAILQ_REMOVE,这些宏的作用比较明显，需要注意的是它们都需要传入head指针和TAILQ_ENTRY定义的标识符。
(我觉得宏最强的地方和最有问题的地方就是它不进行类型检查，最让代码阅读者头痛的就是条件编译^_^)。
2、reb black tree
red black tree（rbt） 是一种近似的二叉平衡树,它的特点如下：
1、根节点是黑色的
2、表示rbt节点结构的空指针都会指向一个空的节点（rchild, lchild, lparent）,而且空节点是黑色的
3、红色节点的rchild/lchild/parent都是红色节点
4、从根节点到空节点的任一路径所包含的黑色节点数是相同的
rbt很重要的一个操作就是子树旋转，它是调整rbt结构的辅助操作。例如：右旋转:
| |
A B 这里需要注意的是旋转前B的右子节点y变成
/ / / / 了A的左子节点
B C =======> x A
/ / / /
x y y C
rbt的插入算法：
按照二叉排序树的流程插入一个新的元素
并把该节点设置为红色
|
调整新的"树"，使它满足rbt的条件
|
如果新节点的父节点为黑色，那么
调整完成
|
如果父节点的颜色为红色，那么进行以下的操作：
假设：cn为当前节点
pn 为当前节点的父节点
pun 为当前节点的父节点的兄弟节点
cn 是pn的左子节点。
1、如果pun是红色，那么将pn和pun都变成黑色，同时把cn设为pn->lparent,重新进入迭代
2、如果pun是黑色，而且cn是pn的右子节点，那么将cn = pn,然后做一次左旋转LR(cn)操作，这样就
可以把调整的树转换到左子树上，这样就把树的结构转换到第三种情况。
3、如果pun是黑色，而且cn是pn的左子节点，那么将pn设置为黑色，并把pn->lparent设置为红色，
同时进行右旋转RR(pn->lparent)-->这时整个调整流程结束。
rbt的删除算法：
按照二叉排序树的删除流程删除一个元素
如果删除的节点是红色的，那么它不会破坏rbt的条件，如果删除的节点是黑色的，那么就需要对新的树进行调整，使它满足tbt的条件
设rn 为替代被删除节点的节点（由于所有"逻辑上悬空"的指针都会指向"特殊的空节点"，所以比如存在替代被删除节点的替代节点），且它是rn->lparent的左子节点（对于右子节点的情况处理方式是对称的）
rcn 为rn的兄弟节点
|
如果cn是红色，那么只要把它变成黑色就满足rbt条件
如果cn是黑色，那么就要根据rcn的颜色分别进行处理：
1、rcn是红色，那么可以知道cn->lparent是黑色，rcn的两个子节点都是黑色，那么把cn->lparent和w的颜色
互换，并进行左旋转操作LR（x->parent）,这样cn就会有一个新的兄弟节点，而且它是黑色的。
2、rcn是黑色，而且rcn的两个子节点都是黑色，这样只要把rcn设为红色，并把当前节点变成它的父节点 cn = cn->lparent 进行递规迭代就可以了
3、rcn是黑色， 而且左子节点rcn->lleft是红色，右子节点rcn->lright是黑色, 那么把rcn和rcn->lleft的颜色
互换，并进行右旋转操作RR(rcn)，这样就会转换到第四中情况，而且cn也有了一个新的兄弟节点
4、rcn是黑色，而且rcn的右子节点是红色，那么将rcn与rcn->parent的颜色互换，并进行左旋转操作
LR(rcn->lparent),
这样就把缺少的黑色节点转移的原来的rcn->lright节点上，而且这个节点是红色的，这时只要把它的颜色转变成黑色就能完成rbt条件的修补。
现在我们对于红黑树的一些算法都比较清楚了，下面看看与红黑树操作相关的几个宏的使用
RB_HEAD(my_rb_tree, rb_entry) rb_head;
struct my_rb_tree * rb_tree;
struct rb_entry {
...
RB_ENTRY(rb_entry) rb_entry_list;
...
};
rb_tree = malloc(sizeof(struct my_rb_tree))
RB_INIT(rb_tree);
...
struct rb_entry * prb1 = NULL, *prb2 = NULL;
...
RB_INSERT(my_rb_tree, rb_tree, prb1 = malloc(sizeof(struct rb_entry)))
RB_INSERT(my_rb_tree, rb_tree, prb2 = malloc(sizeof(struct rb_entry)))
...
struct rb_entry * min = RB_MIN(my_rb_tree, rb_tree);
struct rb_entry * max = RB_MAX(my_rb_tree, rb_tree);
assert(RB_EMPTY(rb_tree))
...
RB_FOREACH(tmp_entry, my_rb_tree, rb_tree)
custom_function(temp_entry);
struct rb_entry * t_entry = NULL;
RB_NEXT(my_rb_tree, rb_tree, t_entry);
...
RB_REMOVE(my_rb_tree, rb_tree, prb1);
...
RB_FIND(my_rb_tree, rb_tree, prb2）
上面的这些操作都比较简单，参数的含义也比较明显，这里就不多说了。
需要注意的是rbt定义的辅助宏：
RB_PROTOTYPE(my_rb_tree, rb_entry, rb_entry_list, compare)：声明一些操作函数，它的参数的含义是：
my_rb_tree: 用户定义的rbt的名称, 它可用于后面的变量定义
rb_entry: rbt中保存的结构体类型
rb_entry_list: rb_tree定义中RB_ENTRY定义的字段成员字段的名称
compare : 比较函数，用于在find算法和remove算法中查找目标元素，它的原型是：int compare(struct rb_entry * a, struct rb_entry* b)
RB_GENERATE(my_rb_tree, rb_entry, rb_entry_list, compare)：产生操作函数的代码, 它的参数的含义和RB_PROTOTYPE的含义是一样的。
2、libevent的处理流程
现在我们看看libevent的基本处理流程；
初始化libevent的运行环境
event_init()
|
event_set(&event, filedescriptor, trigger_event, call_back, *parameter)-->初始化事件的结构
|
event_add(&event, timeinterval)-->增加查询对列中的事件
|
event_dispatch()
event_init
|
创建event_base结构，base = calloc(sizeof(struct event_base))
|
检查系统是否支持clock_gettime, detect_monotic()
获取系统当前的时间（事实上libevent的工作都是基于定时模型，所以提取系统的时间是非常重要的）
gettime(&base->event_tv)
|
初始化保存数据的红黑树和事件队列
RB_INIT(&base->timetree);
TAILQ_INIT(&base->eventqueue);
TAILQ_INIT(&base->sig.signalqueue);
|
初始化IO系统，对于不同的平台的初始化函数是不同的，
现在以freebsd（kqueue）为例，跟踪一下系统的操作流程
|
kq_init(base)
|--->初始化struct kqop结构 kqueueop = calloc(sizeof(struct kop))
| |
| 创建kqueue描述符， kq = kqueue()
| |
| 创建struct kevnet结构队列，用于kevent函数时用于监测的队列
| kqueueop->changes = malloc(NEVENT * sizeof(struct kevent))
| 创建监测返回队列
| |
| kqueueop->events = malloc(NEVENT * sizeof(struct kevnent))
| |
| 测试系统是否真的支持kqueue
| kqueueop->changes[0].ident = -1;
| kqueueop->changes[0].filter = EVFILT_READ;
| kqueueop->changes[0].flags = EV_ADD;
| |
| 当下列情况发生时，就表示该系统并非真的支持kqueue工作方式，一般只有在
| Mac OS X平台上才会有这种情况发生
| kevent(kq, kqueueop->changes, 1, kqueueop->events, NEVENT, NULL) != 1 ||
| kqueueop->events[0].ident != -1 || kqueueop->events[0].flags != EV_ERROR
|
创建优先级队列，它是用于保存被激活的事件
event_base_priority_init(base, 1)
| |-->如果当前有事件是激活的，那么就直接返回-1,否则检查需要创建的队列数是否和目前的
| 队列数一样，如果不一样就释放当前的资源，然后重新分配新的资源。
|
设置全局变量current_base，它在很多函数中是充当默认参数的角色
current_base = base;
return (base);
event_set(struct event * ev, int fd, short events, void(*call_back)(int, short, void*), void *arg)
|
这个函数比较简单，只是简单地初始化事件结构struct event,这里需要注意的是这里使用了在event_init初始化的
全局变量current_base变量，而且event_set中把事件的优先级设置为中等的值
event_add(struct event* ev, struct timeval *tv)
和很多有超时设置的异步io函数一样，event_add的操时参数tv是可选的，在libevent中（以freebsd平台为例）对于
IO的监控其实是分了两个机制:
1、调用kqueue/kevent直接监控IO
2、对于设置了超时的IO，超时置是通过内建的rbt来保存的，对于"阻塞的监控"（反复调用kevent进行操作,也就是
开发者调用了event_dispatch后，直到没有需要监控的IO才返回）,一次调用kevnet的超时时间就是当前时间
到下一个IO超时的时间
清楚了libevent的处理方式，对于event_add的操作就比较清楚了：
如果超时参数tv非空
|----->清除与该事件的相关状态信息（如果该事件已经在超时对列中，那么把该事件从操时队列中删除）
| | (如果该时间由于超时原因被激活，那么把事件从激活对列中删除)
| |
| 将超时时间调整为绝对时间,并把事件加入到rbt中
检查事件的结果标志，将事件分别加入到kqueue的监控队列、信号队列中(这些对列是libevent维护的数据结构，而不是kqueue)
event_queue_insert(base, ev, EVLIST_INSERTED)/event_queue_insert(base, ev, EVLIST_SIGNAL)
|
将事件加入到kqueue监控队列
evsel->add(evbase, ev)--->kq_add(void * arg-->struct kqop*, struct event* )
|
总的来说kq_add函数是根据struct event的参数初始化kevent结构并加入到系统的监测队列中
对于信号-->kev.filter = EVFILT_SIGNAL
"可读"-->kev.filter = EVFILT_READ
"可写"-->kev.filter = EVFILT_WRITE
需要注意的是,读写是可以同时加入kqueue的，但是信号是单独加入kqueue的，这是因为信号的fd并
不是一个有效的IO描述符，kqueue的信号处理和signal/sigaction机制是兼容的，kqueue记录所有的
signal处理，即使是标志了SIG_IGN的信号，但是它的优先级比sigal/sigaction低。
（kev.fflags = NOTE_EOF是为了与select/poll的模式兼容，在读到eof的时候激活事件，对于socket
而言，就是在读完了缓冲区的内容，并且对方已经关闭了写端后会激活事件）
|
把监测的IO加入到kqueue中
kq_insert(kqop, &kev)
kq_add简单的把kev的数据保存到kqop中(当kqop中保存监听事件和激活事件的数组已经满时，进行了
2倍的容量重新分配)
event_dispatch()
|-->event_loop(0)
|-->event_base_loop(current_base, flags)-->这里使用了全局变量current_base作为调度对象，所以
| 它不是线程安全的
event_base_loop(struct event_base *base, int flags)
event_base_loop结合了线程安全和非线程安全的接口
检查base需要监听的信号对列base->sig.signalqueue
设置全局struct event_base * evsignal_base = base
（信号是面向进程的，用一个全局变量来标识信号的处理也很合理，不过开发者需要保证多线程调用event_base中的信号队列只有一个是非空的）
|
重新设置监控对列中的数据结构,(freebsd中就是kevent，不过它不需要设置，所以kq_recalc只是简单地返回0)
检查base->event_gotterm，事件处理函数可以通过修改它的值控制循环的结束(这个也可以用在多线程环境中来终止一个监听线程的工 作)。检查全局变量event_gotsig,这个是全局的接口，主要是方便在单线程环境境下简化编程工作，与event_gotsig配合的回调函数是 event_sigcb
|
调整超时rbt的绝对时间 timeout_correct，这里调整是因为对于没有提供clock_gettime(CLOCK_MONOTONIC)的系统，libevent是 通过gettimeofday()来获得系统当前的时间的，而gettimeofday会受到一些外部因素的影响(例如：ntpupdate等)。但是 timeout_correct的算法只是当系统时间滞后与前一次检测时间 时才会进行超时事件的时间调整，也就是说：
libevent保证超时时间的激活不会大于event_add设定的超时时间,当由于某些原因造成当前系统时间滞后时，
libevent 会对每个事件的唤醒时间进行调整，这是等待时间是不变的，但是如果系统的时间被调整为超前于实际的时间，那么事件的等待时间就会变少。当然这些情况只对于 使用gettimeofday的平台适用，对于提供clock_gettime(CLOCK_MONOTONIC)调用的平台，事件等待的始终是 event_add设定的超时时间。(timeout_correct中修改的正好是rbt的key，不过它是顺序进行相同的修正，所以并没有破坏rbt 的结构)
|
计算最小的内核等待时间(调用kevent的超时时间):
如果没有已经存在激活的事件(由于优先级的原因，有的激活的事件可能还留在低优先级的队列中)，或者非"阻塞"的循环等待模式那么内核等待的时间为零，否则就等待下一个超时值到来的时间
|
进入内核等待evsel->dispatch(base, evbase, tv_p)
kq_dispatch(struct event_base *base, void *arg, struct timeval *tv)
|
如果设定了超时值，那么就将struct timeval 结构转化为struct timespec结构
调用内核检测函数kevnet
res = kevent(kqop->kq, changes, kqop->nchanges, events, kqop->nevents, ts_p);
|
循环检查返回的事件结构
ev = (struct event *)events[i].udata;
如果ev没有设置(ev->ev_events & EV_PERSIST),那么在libevent维护的事件队列中删除对应的事件
event_del(ev);
|
将激活的事件加入到对应的激活队列中
event_active(ev, which, ev->ev_events & EV_SIGNAL ? events[i].data : 1);
|
处理超时事件timeout_process
timeout_process的处理比较简单，它通过枚举寻找rbt中已经超时的事件，并把该事件从超时事件队列中
删除，同时把事件加入到激活对列中
|
处理激活队列中的事件
event_process_active(base);
这里有两个地方需要注意的：
1、event_process_active是根据优先级来调度已经激活的事件队列的，而且一次只会处理一个非空的事件队 列，如果高优先级(下标小的队列)的队列一直有激活的事件，那么低优先级队列就会一直被滞后。
2、回调函数可以通过修改ev_pncalls指向的变量的值来中断同一个事件的多次激活，而且可以通过全局变量
event_gotsig来中断整个event_process_active调用。
对于libevent的基本处理流程我们已经比较清楚了。
libevent中兼容了多个系统平台的IO的特点，这里就不展开了^_^。
3、整体感觉
1、libevent使用了很经典的通过结构体的函数指针来维护不同平台的差异。
2、libevent中通过rbt来维护超时事件的信息，在效率上有很可观的表现，同时也考虑了时间的修正问题，对我来说很有启发性^_^。
(本blog信息均为原创，装载请注明出处^_^)
