先总体说下select引擎与libevent结合的过程(其它引擎是同样的道理)
/*我们使用libevent的一般调用流程如下:(base->evsel是全局的事件引擎,其数据结构见下面2.相关的数据结构)
0. 全局初始化event_init()--决定使用哪个引擎;
event_init()引用event_base_new(),后者关键片断在于:
1. event_set()只是对要加入的事件进行初始化:
2. event_add()加入到事件列表--调用了evsel->add(evbase, ev):
evsel->add指向一个具体的事件引擎的add接口,在这里是select_add(),把要监测的事件加入select引擎中来
3. event_dispatch()--它调用的核心函数是evsel->dispatch(),也即select_dispatch()函数
select_dispatch()实际上调用了传统I/O复用的系统调用:select(...),代码如下
*/
1. libevent如何与select引擎结合?
首先,决定使用何种引擎是在编译过程中,我的系统支持select,于是在config.h中生成
#define HAVE_SELECT 1
对应地,在event.c里有
#ifdef HAVE_SELECT
extern const struct eventop selectops;
#endif
这里面的selectops在select.c中定义,它的各个成员实际上与event_add等主要API一一对应,
比如event_add对应select_add, event_dispatch对应select_dispatch等
const struct eventop selectops = {
"select",
select_init,
select_add,
select_del,
select_dispatch,
select_dealloc,
0
};
其次,在event.c中还有一个数据结构:
/*这里会有很多ops,但libevent采用时会按先后顺序!*/
static const struct eventop *eventops[] = {
...
#ifdef HAVE_POLL
&pollops,
#endif
#ifdef HAVE_SELECT
&selectops,
#endif
...
}
接着,我们得找到eventops被引用的地方(仍然在event.c里):
event_init()引用event_base_new(),下面是后者的关键片断:
for (i = 0; eventops[i] && !base->evbase; i++) {
//在这里决定引擎的初始化,遵循靠前优先的原则,一旦某个比如select的初始化完成,就跑出for循环!
base->evsel = eventops[i];
base->evbase = base->evsel->init(base);
}
if (base->evbase == NULL)
event_errx(1, "%s: no event mechanism available", __func__);
可见运行的时候, 正常的话会选择一个事件引擎,供以后使用!如果系统不支持任何的引擎,则出错返回!
2. 相关的数据结构!
全局的引擎结构变量是eventop,在以后所有evsel->dispatch,evsel->add等都是引用的实际绑定的引擎
这里的fd_set有四类,不知道为什么,传统的只有两类,一为读,一为写!
/*事件数量?*/
n_events = (sop->event_fdsz/sizeof(fd_mask)) * NFDBITS;
根据select_add中的下面代码:
/*根据事件类型(读,写),打开相应的selectop中的相应变量!*/
判断,select引擎只截获读/写事件;
在用位图记录事件的时候,我觉得他们最多只能记录32