一个程序渣渣的小后院

libevent监听的event有以下几种文件描述符/套接字，没有设定超时时长信号文件描述符/套接字，设定超时时长对于时间，libevent内部的时间管理是通过最小堆实现的，原因如下既然某些fd有规定的超时时长，那么io多路复用函数就不能永久阻塞，需要设定一个超时时长（最后一个参数）用户在使用event_add设定的时间是相对于event_add调用的相对时间，这就导致所有具有超时时长的

libevent核心结构是event_base和event，接下来主要介绍event结构/* event的定义的主要部分 */struct event { /* ... */ /* event监听的描述符,也可以是信号值 */ evutil_socket_t ev_fd; /* 事件驱动主循环 */ struct event_base *ev_base; s

libevent中事件驱动的大体流程如下/* 创建事件驱动 */struct event_base* base = event_base_new(); /* *创建一个事件 *@param base: 事件驱动 *@param fd: event对应的文件描述符，通常是通过socket创建的套接字 *@param EV_READ: 想要监听fd的哪些事件，EV_READ表示监听fd是否可

框架设计思路libevent使用统一事件源将所有问题都转化为event，比如将套接字/信号/描述符都在内部转化为event，由相应的io多路复用函数进行监控。为了提供对超时event的支持，libevent将所有的超时时间都转化为绝对时间，这就将杂乱无章的超时event有序管理起来，同时采用最小堆存储那些具有超时时间的event，这样当堆顶event没有超时，那么堆中所有event都不会超时。

event_base是libevent的事件驱动，也是Reactor模式的直接体现。任何使用libevent的代码最开始都需要创建一个base，之后的任何接口函数都和这个base关联着，下面是struct event_base的定义struct event_base { /* io多路复用函数的统一接口 */ const struct eventop *evsel; /* io

libevent内部采用了reactor模型 所谓reactor模型，其实就是一套事件注册机制，用来解决单线程的阻塞问题。reactor核心思想是将事件和相应事件发生时想要调用的函数都记录下来，在事件驱动循环开始后进行统一监测，当某个事件发生，会直接调用相应事件的处理函数。 比如说有事件event1，event2，event3。相应事件发生时想要调用的回调函数是cb1，cb2，cb3。然而如果是

libevent在对文件描述符，套接字进行监控时直接放到event，这些event通过io多路复用函数进行监控，然而对应信号来说io复用函数却无能为力，为了解决问题，libevent采用统一事件源的方式，即将信号也表现成event的形式，用到了socketpair套接字对socketpair套接字对 套接字对也是通信方式的一种，在进程间通信时相比于管道和命名管道而言更简单，也更安全 lin

因为是非阻塞监听事件的发生，所以内部其实还是采用io多路复用函数实现的。 又因为可供选择的io函数很多，linux下有epoll, poll, select等，window下有ICOP, select等，所以libevent需要在程序启动时选择一个合适的io多路复用函数，合适的依据是系统支持，为了实现跨平台io函数的效率尽量高用户是否主动设置了不想使用的io函数为了解决跨平台，libeve