libevent源码分析之event_io_map与event_signal_map

最新推荐文章于 2022-01-13 11:30:13 发布

yuanhaitaozz

最新推荐文章于 2022-01-13 11:30:13 发布

阅读量1.3k

点赞数 1

分类专栏： Libevent源码分析

本文链接：https://blog.youkuaiyun.com/u012062760/article/details/46521735

版权

Libevent源码分析专栏收录该内容

14 篇文章

订阅专栏

首先，文章主要借鉴 http://blog.youkuaiyun.com/luotuo44/article/details/38403241，十分感谢！

现在，我们来看看libevent中使用的哈希表

在学习此数据结构之前，要知道一个事实，什么时候会使用到这个哈希表：

/* On some platforms, fds start at 0 and increment by 1 as they are
   allocated, and old numbers get used.  For these platforms, we
   implement io maps just like signal maps: as an array of pointers to
   struct evmap_io.  But on other platforms (windows), sockets are not
   0-indexed, not necessarily consecutive, and not necessarily reused.
   There, we use a hashtable to implement evmap_io.
*/

可见，比如windowns平台上，产生的socket，不像linux里一样从小到大安排不仅连续还可能会重用，而是给出一个飘忽不定的数，于是才使用哈希表实现的evmap_io来处理
【由此也可见，在linux等平台上的evmap_io是十分简单的，只是单纯的数组来实现evmap_io】

如下是整个哈希表的结构体，可以通过分析其中的成员来认识这个哈希表具体的结构：

struct event_io_map {                                                         
   /* The hash table itself. */                                        
   struct event_map_entry **hth_table;                                            
   /* How long is the hash table? */                                   
   unsigned hth_table_length;                                          
   /* How many elements does the table contain? */                     
   unsigned hth_n_entries;                                             
   /* How many elements will we allow in the table before resizing it? */ 
   unsigned hth_load_limit;                                            
   /* Position of hth_table_length in the primes table. */             
   //之前接触过STL的哈希表,其中数组长度的增长是按照素数增长的,我想这里也是这样,所以下面当前长度在素数数组中的位置
   int hth_prime_idx;                                                  
 }

struct event_map_entry {
         HT_ENTRY(event_map_entry) map_node;
         evutil_socket_t fd;
         union { /* This is a union in case we need to make more things that can
                            be in the hashtable. */
                 struct evmap_io evmap_io;
         } ent;
 };

//关于HT_ENTRY，指的是如果定义了某个宏,除了相同部分的指向下一个节点的指针，就另外多出一个变量
//该变量多出来干嘛的呢？
//根据对整个哈希表的理解,可以在其他操作源代码中看出,以后判断event结构体插在哈希表的哪一个位置，不是直接根据fd取模判断的,还要将fd经过某种处理后再通过取模放入哈希表中的某位置
//那样岂不是每次想知道某event在哪个bucket都要对fd进行某种处理，然后再判断？ 
//如果定义了HT_CACHE_HASH_VALUES，那么多出来的hte_hash变量就是存这个fd经过某种处理后的值的！ 
#ifdef HT_CACHE_HASH_VALUES
#define HT_ENTRY(type)                          \
  struct {                                      \
    struct type *hte_next;                      \
    unsigned hte_hash;                          \
  }
#else
#define HT_ENTRY(type)                          \
  struct {                                      \
    struct type *hte_next;                      \
  }
#endif

//可以看到的是，对于某一个fd，这里也使用了event_list
//然而这个event_list使用的就是上一章讲到的TAILQ,这么说那为什么对于一个fd会有好多event呢？
//这是因为libevent允许用同一个文件描述符或信号值，调用event_add多次。此时，同一个文件描述符或信号值就有多个event与其相关了
struct evmap_io {
         struct event_list events;
         ev_uint16_t nread;
         ev_uint16_t nwrite;
 };

回顾之前对SGI STL中哈希表的认识，哈希表解决冲突问题的方式就是使用开链法，其余还可以使用线性探索，二次线性等
通过 struct type** hth_table，以及HT_ENTRY中的next指针，我们就可以发现其使用的解决冲突的方法也是开链法。
整体的结构如下图：

整体的操作这里就不再详谈了,读了一遍后发现与STL中的哈希表类似,只是依旧全是用宏实现的操作（不过部分内容属于没看懂要干嘛，以后遇到再说）
所有的操作中，都是以event_map_entry为基本单位操作的，并没有深入到event，意味着将来还是要通过调用者来进一步处理的

接着来看看在libevent中的实际应用
分析的函数是evmap_io_add

//要看此函数，最好在理解了此函数下面的宏讲解再回头来看
int
evmap_io_add(struct event_base *base, evutil_socket_t fd, struct event *ev)
{
    const struct eventop *evsel = base->evsel;
    struct event_io_map *io = &base->io;
    struct evmap_io *ctx = NULL;
    int nread, nwrite, retval = 0;
    short res = 0, old = 0;
    struct event *old_ev;

    EVUTIL_ASSERT(fd == ev->ev_fd);

    if (fd < 0)
        return 0;

#ifndef EVMAP_USE_HT
    if (fd >= io->nentries) {
        if (evmap_make_space(io, fd, sizeof(struct evmap_io *)) == -1)
            return (-1);
    }
#endif
    GET_IO_SLOT_AND_CTOR(ctx, io, fd, evmap_io, evmap_io_init,
                         evsel->fdinfo_len);
        //至此,我们知道了应该把事件插在哪里
        //于是着手处理一些细节问题
    nread = ctx->nread;
    nwrite = ctx->nwrite;

        //查看原来的哈希表中fd是注册的什么事件
        //以下细节暂时不去理解，这里涉及到对整个libevent的理解
    if (nread)
        old |= EV_READ;
    if (nwrite)
        old |= EV_WRITE;

    if (ev->ev_events & EV_READ) {
        if (++nread == 1)
            res |= EV_READ;
    }
    if (ev->ev_events & EV_WRITE) {
        if (++nwrite == 1)
            res |= EV_WRITE;
    }
    if (EVUTIL_UNLIKELY(nread > 0xffff || nwrite > 0xffff)) {
        event_warnx("Too many events reading or writing on fd %d",
            (int)fd);
        return -1;
    }
    if (EVENT_DEBUG_MODE_IS_ON() &&
        (old_ev = TAILQ_FIRST(&ctx->events)) &&
        (old_ev->ev_events&EV_ET) != (ev->ev_events&EV_ET)) {
        event_warnx("Tried to mix edge-triggered and non-edge-triggered"
            " events on fd %d", (int)fd);
        return -1;
    }

    if (res) {
        void *extra = ((char*)ctx) + sizeof(struct evmap_io);
        /* XXX(niels): we cannot mix edge-triggered and
         * level-triggered, we should probably assert on
         * this. */
        if (evsel->add(base, ev->ev_fd,
            old, (ev->ev_events & EV_ET) | res, extra) == -1)
            return (-1);
        retval = 1;
    }

    ctx->nread = (ev_uint16_t) nread;
    ctx->nwrite = (ev_uint16_t) nwrite;

        //最后插入在同一个fd的TAILQ队列里
    TAILQ_INSERT_TAIL(&ctx->events, ev, ev_io_next);

    return (retval);
}

其中最关键的函数就是函数内的一个宏：

GET_IO_SLOT_AND_CTOR(ctx, io, fd, evmap_io, evmap_io_init, evsel->fdinfo_len);

这个宏内调用了两个宏,值得注意的是宏_HT_FIND_OR_INSERT的最后两个参数略长...它的原型是：

#define _HT_FIND_OR_INSERT(name, field, hashfn, head, eltype, elm, var, y, n) ...

#define GET_IO_SLOT_AND_CTOR(x, map, slot, type, ctor, fdinfo_len)    \
    do {                                \
        struct event_map_entry _key, *_ent;            \
        _key.fd = slot;                        \
        _HT_FIND_OR_INSERT(event_io_map, map_node, hashsocket, map, \
            event_map_entry, &_key, ptr,            \
            {                            \
                _ent = *ptr;                \
            },                            \
            {                            \
                _ent = mm_calloc(1,sizeof(struct event_map_entry)+fdinfo_len); \
                if (EVUTIL_UNLIKELY(_ent == NULL))        \
                    return (-1);            \
                _ent->fd = slot;                \
                (ctor)(&_ent->ent.type);            \
                _HT_FOI_INSERT(map_node, map, &_key, _ent, ptr) \
                });                    \
        (x) = &_ent->ent.type;                    \
    } while (0)

理解这个宏,那么evmap_io_add函数就可以明白大部分了
将宏进行gcc -E的预编译后,得到如下内容：

do{
    //这个_ent就是将来我们可能要添加到哈希表中去的一个元素
    //那_key是干嘛用的 ？ 居然还不是指针类型的！
    //这个key是用来给我在哈希表中查找,在哈希表中fd代表的事件(链)是不是已经存在了！
    //存在的话,那这个key因为是栈中申请的,不需要我们去处理(释放)
    //不存在的话，就创建一个
    struct event_map_entry _key, *_ent;
    _key.fd = fd;

    struct event_io_map *_ptr_head = io;
    //看到这个二级指针,我们就该想到哈希表中的FIND_P函数了
    struct event_map_entry **ptr;

    //事先要判断是否需要扩充哈希表
    if (!_ptr_head->hth_table
                || _ptr_head->hth_n_entries >= _ptr_head->hth_load_limit)
    {
        event_io_map_HT_GROW(_ptr_head,
            _ptr_head->hth_n_entries + 1);
    }

    #ifdef HT_CACHE_HASH_VALUES
        do{
            (&_key)->map_node.hte_hash = hashsocket((&_key));
        } while(0);
    #endif

    //这里在整个哈希表中查找fd是否已经存在在哈希表中了，之前谈到过，哈希表只能允许一个fd存在，然而一个fd可以联系到多个event结构体
    //于是我们要看看哈希表中是否已经有了这个fd，如果没有就创建，然后返回它的地址；如果存在这个fd了，我们就要返回这个entry地址。给我们用来把事件插进去！
    ptr = _event_io_map_HT_FIND_P(_ptr_head, (&_key));  

    if (*ptr)
    {
        _ent = *ptr;
    }
    else
    {
        //不存在的话，就创建一个entry,可以让我们把事件存进去
        _ent = mm_calloc(1, sizeof(struct event_map_entry) + evsel->fdinfo_len);
        if (EVUTIL_UNLIKELY(_ent == NULL))
            return (-1);

        _ent->fd = fd;
        (evmap_io_init)(&_ent->ent.evmap_io);

#ifdef HT_CACHE_HASH_VALUES
        do
        {
            ent->map_node.hte_hash = (&_key)->map_node.hte_hash;
        }while(0);
#endif
        _ent->map_node.hte_next = NULL;

        //既然我们没有在哈希表的某bucket里找到相同的fd，那么此时ptr指针肯定是存的是哈希表某bucket里最后一个元素的next指针的地址
        *ptr = _ent;
        ++(io->hth_n_entries);
        }

        //于是我们取得了该entry的地址,好让我们过会儿去把事件插进去
    (ctx) = &_ent->ent.evmap_io;
}while (0)

接下来就认识一下较为简单的event_signal_map

上面讲到,在windows这种平台上我们会定义event_io_map为比较复杂的哈希表类型,而在linux等平台上,libevent则采用了简单的哈希表类型
差别在于,windows平台上我们会使用取模得到事件应该插入在哈希表上的位置，这样会导致不同fd的事件在哈希表的同一个bucket上,于是需要链表将这些不同fd事件连接起来,又要考虑到一个fd可以有多个event结构体,又要通过链表来连接，所以整个结构体显得较为复杂

而在linux等平台上,得到的fd不仅是从小到大的,而且可能是连续的,而且可能会重用之前关闭的,这就使fd的值不会太大或太随机,于是在此平台上寻找某fd事件对应的哈希表中bucket时,不令其取模,而是直接找对应的位置. 若还不理解,那么下面的内容可以帮助理解.

这里不讲此平台上的event_io_map了,因为:

#ifdef EVMAP_USE_HT
#include "ht-internal.h"
struct event_map_entry;
HT_HEAD(event_io_map, event_map_entry);
#else
#define event_io_map event_signal_map
#endif

linux等平台上的event_io_map可以这样设计, 那windows和linux等平台的event_signal_map为什么可以同时使用这个结构体呢？
因为linux等平台上的信号数量和windows平台上的信号数量都很少, 只有二位数个或个位数个。

接下来看看event_signal_map：

//虽然使用的是void **, 但实际使用的时候自然是用的evmap_signal 
//在了解windows下的event_io_map后再来看这个,显得十分简单易懂
struct event_signal_map
{
    void **entries;
    int nentries;
};

struct evmap_signal {
    //event_list也就是TAILQ
    struct event_list events;
};

给出的操作函数本就不多，因为数据结构比较简单，就挑下面一个拿出来看看
接下来看看此数据结构的操作函数：

static int
evmap_make_space(struct event_signal_map *map, int slot, int msize)
{
    if(map->nentries <= slot)
    {
        int nentries = map->nentries?map->nentries:32;
        void **tmp;

        while(nentries <= slot)
            nentries <<= 1;

        //这里使用的是realloc, 也是讲究的. 因为这种简单的哈希表在使用realloc后是无需重新调整的,因为fd代表的事件插入时是直接插入的,不需要取模什么的
        //如果使用malloc,还要原封不动的搬过来明显麻烦
        tmp = (void **)mm_realloc(map->entries, nentries*msize);
        if(NULL == tmp)
            return -1;

        memset(&tmp[map->nentries], 0, 
            (nentries - map->nentries) * msize);

        map->nentries = nentries;
        map->entries = tmp;
    }
    return 0;
}

接下来看看这种数据结构在libevent中的应用：

int
evmap_signal_add(struct event_base *base, int sig, struct event *ev)
{
    const struct eventop *evsel = base->evsigsel;
    struct event_signal_map *map = &base->sigmap;
    struct evmap_signal *ctx = NULL;

    if (sig >= map->nentries) {
        if (evmap_make_space(
            map, sig, sizeof(struct evmap_signal *)) == -1)
            return (-1);
    }
    GET_SIGNAL_SLOT_AND_CTOR(ctx, map, sig, evmap_signal, evmap_signal_init,
        base->evsigsel->fdinfo_len);

    if (TAILQ_EMPTY(&ctx->events)) {
        if (evsel->add(base, ev->ev_fd, 0, EV_SIGNAL, NULL)
            == -1)
            return (-1);
    }

    TAILQ_INSERT_TAIL(&ctx->events, ev, ev_signal_next);

    return (1);
}

核心依旧在这个宏上：

GET_SIGNAL_SLOT_AND_CTOR(ctx, map, sig, evmap_signal, evmap_signal_init,
        base->evsigsel->fdinfo_len);

理解了这个宏那么evmap_signal_add函数就容易理解了
因为下面的内容并不难理解，就直接在上面注释了

#define GET_SIGNAL_SLOT_AND_CTOR(x, map, slot, type, ctor, fdinfo_len)    \
    do {                                \
                //因为数据结构的简单，所以操作就显得简单多了
                //如果不存在一个可以插入event的地方，那就需要创建了
        if ((map)->entries[slot] == NULL) {            \
            (map)->entries[slot] =                \
                mm_calloc(1,sizeof(struct type)+fdinfo_len); \
            if (EVUTIL_UNLIKELY((map)->entries[slot] == NULL)) \
                return (-1);                \
                        //记得初始化一下
            (ctor)((struct type *)(map)->entries[slot]);    \
        }                            \
        (x) = (struct type *)((map)->entries[slot]);        \
    } while (0)