libevent源码学习（1）：日志及错误处理

目录

错误处理函数

函数声明

__attribute__指令

函数定义

可变参数宏

_warn_helper函数

日志处理

event_log日志处理入口

日志处理回调函数指针log_fn

设置日志处理回调函数event_set_log_callback

错误处理

event_exit错误处理入口

错误处理回调函数指针fatal_fn

设置错误处理回调函数event_set_fatal_callback

日志及错误处理流程

---

以下源码均基于libevent-2.0.21-stable。

日志及错误处理，虽说不是libevent的核心，甚至说是有些“简陋”，但其也是必不可少的部分。在libevent的源码中，仔细观察可以发现，很多函数中都调用了event_warn、event_err之类的函数，而这些函数就是在日志与错误处理模块中实现的，除此之外，在libevent的日志及错误处理的实现中，还使用到了反应堆中回调函数的思想，因此，个人觉得，在分析libevent的核心部分之前，先看看比较容易的日志及错误处理这一块还是有些必要的。

错误处理函数

函数声明

libevent的日志及错误处理模块在log.c和log-internal.h中。日志及错误处理函数声明位于log-internal.h中，主要包含以下内容：

这些都是错误处理函数的声明，无需多说，需要注意的是，这里的函数末尾还多了一些语句，如EV_CHECK_FMT(2,3) EV_NORETURN，很明显，这些都是宏定义，那这些宏定义有什么作用呢？

__attribute__指令

跳转到宏定义处，如下所示：

也就是说，这里的宏定义实际上是定义的__attribute__，使用了GNU C的__attribute__机制。它实际上是对编译器进行指示，对于函数相当于是一个修饰作用。比如说这里的

1. #define EV_CHECK_FMT(a,b) __attribute__((format(printf, a, b)))
2. #define EV_NORETURN __attribute__((noreturn))

对于event_err函数来说，参数中含有可变参数，函数由EV_CHECK_FMT(2,3)  和EV_NORETURN修饰，

其中EV_CHECK_FMT(2,3)  对应与__attribute__((format(printf, 2, 3)))，提示编译器按照printf函数格式化的形式来对event_err函数进行编译，2表示第2个参数为格式化字符串，3表示格式化的可变参数从第3个参数开始。简单来说，就是提示编译器从第3个参数开始按照第2个参数字符串的格式进行格式化；

EV_NORETURN表示event_err函数没有返回值，也不能有返回值。

函数定义

先来看看上述声明的处理函数的定义，位于log.c文件中，如下所示：

1. void
2. event_err(int eval, const char *fmt, ...)
3. {
4. va_list ap;
5.  
6. va_start(ap, fmt);
7. _warn_helper(_EVENT_LOG_ERR, strerror(errno), fmt, ap);
8. va_end(ap);
9. event_exit(eval);
10. }
11.  
12. void
13. event_warn(const char *fmt, ...)
14. {
15. va_list ap;
16.  
17. va_start(ap, fmt);
18. _warn_helper(_EVENT_LOG_WARN, strerror(errno), fmt, ap);
19. va_end(ap);
20. }
21.  
22. void
23. event_sock_err(int eval, evutil_socket_t sock, const char *fmt, ...)
24. {
25. va_list ap;
26. int err = evutil_socket_geterror(sock); //宏定义为errno
27.  
28. va_start(ap, fmt);
29. _warn_helper(_EVENT_LOG_ERR, evutil_socket_error_to_string(err), fmt, ap);
30. va_end(ap);
31. event_exit(eval);
32. }
33.  
34. void
35. event_sock_warn(evutil_socket_t sock, const char *fmt, ...)
36. {
37. va_list ap;
38. int err = evutil_socket_geterror(sock);
39.  
40. va_start(ap, fmt);
41. _warn_helper(_EVENT_LOG_WARN, evutil_socket_error_to_string(err), fmt, ap);
42. va_end(ap);
43. }
44.  
45. void
46. event_errx(int eval, const char *fmt, ...)
47. {
48. va_list ap;
49.  
50. va_start(ap, fmt);
51. _warn_helper(_EVENT_LOG_ERR, NULL, fmt, ap);
52. va_end(ap);
53. event_exit(eval);
54. }
55.  
56. void
57. event_warnx(const char *fmt, ...)
58. {
59. va_list ap;
60.  
61. va_start(ap, fmt);
62. _warn_helper(_EVENT_LOG_WARN, NULL, fmt, ap);
63. va_end(ap);
64. }
65.  
66. void
67. event_msgx(const char *fmt, ...)
68. {
69. va_list ap;
70.  
71. va_start(ap, fmt);
72. _warn_helper(_EVENT_LOG_MSG, NULL, fmt, ap);
73. va_end(ap);
74. }
75.  
76. void
77. _event_debugx(const char *fmt, ...)
78. {
79. va_list ap;
80.  
81. va_start(ap, fmt);
82. _warn_helper(_EVENT_LOG_DEBUG, NULL, fmt, ap);
83. va_end(ap);
84. }

以上都是错误处理函数，可以发现，这些函数都是有共同点的：它们的参数除了一个用于格式化的字符串fmt，其他都是可变参数。而在函数体内，也大致相同：一个是可变参数宏，一个是调用了_warn_helper函数，下面先来说下这两个东西。

可变参数宏

可变参数宏常用于C语言中的变参函数，所谓变参函数是指在定义函数的时候无法确定函数有多少个参数，就像你要定义一个序列求和函数，但是你并不知道这个序列有多少个元素，那么就可以使用可变参数宏。另一个例子就是printf函数，实际上printf函数就是用可变参数宏实现的。

常用的可变参数宏有以下几个：va_list、va_start、va_arg和va_end，

其中va_list是一个指向参数列表的指针类型，使用时直接用该类型定义一个变量即可，如上面的va_list ap；

va_start是用来指定最后一个非可变参数（也就相当于指明了可变参数列表的起始位置），如上面的错误处理函数最后一个非可变参数是fmt，因此调用方式为va_start(ap,fmt)，其中ap就是刚刚定义的va_list ap；

va_arg用来获取下一个可变参数，由其返回值实现。它需要输入两个参数，一个是va_list变量，也就是这里的ap，另一个就是参数的类型，比如说这里当前参数fmt类型为const char *，那么就需要使用va_arg(ap,const char *);

va_end就不用说了，既然使用了va_start，那么就应当成对使用va_end。

为什么可以这样来获取可变参数呢？这是因为函数的参数都是放在栈中的，并且函数的参数是从从右至左依次入栈，第一个参数地址最低，最后一个参数地址最高，函数原型中相邻的参数在物理地址上也是相邻的，因此调用va_start先让ap指针指向最后一个非可变参数fmt，fmt的类型是const char *类型，占据的大小为sizeof(fmt)，因此此时地址加上sizeof(fmt)就是第一个可变参数的地址了，因此获取下一个可变参数就要用到va_arg(ap,const char*)。

回到错误处理函数中，每个函数都调用了va_list、va_start和va_end，那va_arg呢？那就只能是通过_warn_helper函数来调用了。

_warn_helper函数

先来看看__warn_helper函数的声明，如下所示：

static void _warn_helper(int severity, const char *errstr, const char *fmt,va_list ap);

再来看看是怎么用的，以event_err为例，其调用方式为

_warn_helper(_EVENT_LOG_ERR, strerror(errno), fmt, ap);

这里传入了4个参数，第1个参数是一个宏，根据函数声明中的描述severity，意味“严重性”，这里传入的参数为_EVENT_LOG_ERR，跳转到其定义如下：

可以发现，这实际上就是用于说明出现的消息的严重性，是什么类型的：debug、message、warning or error。

再来看第2个参数，这是一个字符串类型，根据声明中的errstr和实参strerror(errno)可以知道，这实际上就是一个描述错误消息的字符串，是不需要再自行实现的。第3个参数就是调用event_err时传入的格式化字符串fmt。最后一个参数是前面定义的va_list变量ap。

从这4个参数来看，第1个参数是指明消息类型，第2个参数是系统自带的描述错误信息的，第3个和第4个参数一起用来将可变参数进行格式化。

这里需要注意的是，第2个参数错误信息是跟用户无关的，每个错误本身就对应一个描述错误信息的字符串。而第3个和第4个参数是调用者调用消息处理函数时需要格式化字符串和可变参数，如下所示：

其他处理函数的调用方式都大同小异，就不多说了。

_warn_helper函数定义如下：

1. static void
2. _warn_helper(int severity, const char *errstr, const char *fmt, va_list ap) //将需要格式化的字符串与报错信息合并errstr为报错信息，fmt为可变参数格式化的字符串
3.  
4. {
5. char buf[1024];
6. size_t len;
7.  
8. if (fmt != NULL) //如果fmt非空，说明可变参数需要进行格式化
9. evutil_vsnprintf(buf, sizeof(buf), fmt, ap); //将可变参数格式化后的字符串写入buf中
10. else
11. buf[0] = '\0';
12.  
13. if (errstr) { //如果errstr非空
14. len = strlen(buf); //如果至少还能放下冒号、空格和一个终止符（对应“： %s”）
15. if (len < sizeof(buf) - 3) {
16. evutil_snprintf(buf + len, sizeof(buf) - len, ": %s", errstr); //buf+len定位到buf有效字符的末尾的后一个位置，
17. // sizeof(buf)-len限制最多只能填满buf，不能越界
18. //换句话说，就是在buf后面追加“: ”+errstr
19. }
20. }
21.  
22. event_log(severity, buf);
23. }

这里调用了一个evutil_vsnprintf函数，它实际上就相当于vsnprintf，evutil_vsnprintf(buf, sizeof(buf), fmt, ap);就是将通过fmt和可变参数格式化后的字符串从地址buf开始写入，毫无疑问，前面所说缺少的va_arg就是在evutil_vsnprintf进行调用的。通过这一步，就相当于将调用event_err时输入的字符串格式化后放到了buf中。

接下来判断errstr，前面说过，errstr实际上就是错误消息对应的描述性字符串，如果errstr非空，那么就试图将errstr字符串添加到buf的后面，如何实现的呢？首先通过strlen获取buf的实际长度，sizeof获取buf所占空间大小(strlen计算终止符以前的大小，sizeof计算整个buf所占的空间大小)。

这里会判断strlen(buf)是否小于sizeof(buf)-3，如果为真的话就表示buf所占的1024个字节空间至少还能再放下3个字节(包括终止符)，这条判断有什么用呢？再往下面看。

这里调用了evutil_snprintf，而在evutil_snprintf函数内部调用了evutil_vsnprintf函数，因此evutil_snprintf(buf + len, sizeof(buf) - len, ": %s", errstr);一句的作用是将用errstr格式化": %s"后的字符串从地址buf+len开始写入。buf就是char buf[1024]的首地址，buf+len就相当于定位到了当前buf字符串的末尾再往后一位，从该位开始先写入": "(一个冒号加一个空格)，再写入errstr。也就是说，evutil_snprintf的作用就是将调用时输入的格式化字符串fmt和错误描述字符串errstr拼接在一起，中间用": "连接，这也就解释了为什么前面需要判断剩余空间是否小于3，这3个字节空间就是用来放一个冒号、一个空格和一个终止符的。如果小于3，说明连“: ”都放不下了就直接跳出，如果不小于3，说明至少还能放下“: ”。

buf拼接好了之后会再调用一个event_log(severity, buf);函数，将severity和处理后的buf字符串传入。从函数名就能猜出来，这与日志处理相关。

日志处理

event_log日志处理入口

event_log函数定义如下：

1. static void
2. event_log(int severity, const char *msg)
3. {
4. if (log_fn) //如果日志回调函数非空，则调用回调函数
5. log_fn(severity, msg);
6. else { //如果未定义日志回调函数，则直接在终端输出信息："[severity] msg"
7. const char *severity_str;
8. switch (severity) {
9. case _EVENT_LOG_DEBUG:
10. severity_str = "debug";
11. break;
12. case _EVENT_LOG_MSG:
13. severity_str = "msg";
14. break;
15. case _EVENT_LOG_WARN:
16. severity_str = "warn";
17. break;
18. case _EVENT_LOG_ERR:
19. severity_str = "err";
20. break;
21. default:
22. severity_str = "???";
23. break;
24. }
25. (void)fprintf(stderr, "[%s] %s\n", severity_str, msg);
26. }
27. }

event_log函数有两个参数，第一个serverity反映消息类型，第二个参数是字符串类型，这里传入的实际上就是前面处理后描述错误信息的buf字符串。

这里首先会先判断log_fn，如果log_fn非空，则执行log_fn(severity,msg)，如果log_fn为空则执行else部分。

先来看看log_fn为空的情形，这一部分很简单，每一类severity都对应了相应的severity_str，然后通过fprintf将前面处理后描述错误信息的buf字符串(在这里就是形参msg)按"[%s] %s\n"形式格式化，最终输出到标准错误输出stderr，打印到终端屏幕。

那么log_fn是什么呢？log_fn非空又对应什么呢？

日志处理回调函数指针log_fn

跳到定义查看如下：

static event_log_cb log_fn = NULL;

这里log_fn是一个event_log_cb类型，看到cb就应该联想到callback，因此这很可能就是一个log_cb日志回调函数，跳转查看其定义：

typedef void (*event_log_cb)(int severity, const char *msg);

由此可知，event_log_cb是由typedef定义的函数指针类型，且指向的函数返回值为void，参数为(int severity, const char *msg)。也就是说，static event_log_cb log_fn = NULL;一句的作用实际上是将log_fn定义为一个函数指针变量，其应当指向一个返回值为void，含两个参数int severity和const char *msg的函数，初始化为NULL。

也就是说，在一开始log_fn是为空的，那么如何让log_fn非空呢？

设置日志处理回调函数event_set_log_callback

event_set_log_callback函数的定义非常简单：

1. void
2. event_set_log_callback(event_log_cb cb)
3. {
4. log_fn = cb;
5. }

可见，该函数的参数也是一个event_log_cb类型，即函数指针，该函数的作用就是将传入的函数指针赋给log_fn。

换句话说，只要这里传入的cb不为空，那么调用event_set_log_callback函数后log_fn就指向了cb所对应的函数，log_fn也就非空，那么再回到event_log函数中，判断log_fn为真，就会直接执行log_fn(severity,msg)，这里就相当于以severity,msg为参数，调用了cb所对应的函数。

因此，只需要通过event_log_cb传入自定义的日志回调函数的指针(可以直接传入函数名)，那么在处理日志的时候就会执行自定义的日志回调函数。

另外还需要注意的一点是，如果event_log_cb函数传入的实参为NULL，那么log_fn又会重置为Null，然后执行默认处理行为：将错误信息打印到终端屏幕上。

错误处理

event_exit错误处理入口

前面错误处理入口函数部分，提到每个入口函数都有相似的地方：可变参数宏和调用_warn_helper函数，通过这两点完成了日志处理功能，那么错误处理又是在哪里完成的呢？还是回到哪些错误处理入口函数，这次来看看它们之间的不同。

可以发现，如果是error相关的处理函数(event_err、event_sock_err和event_errx)，那么在函数末尾会调用一个event_exit(eval);而其他的warn、msg一类的函数则没有调用event_exit(eval);这是符合逻辑的，出现了error程序就应当终止，因此这里的event_exit函数就应当是错误处理函数了。

跳转到event_exit函数的定义，如下所示：

1. static void
2. event_exit(int errcode) //
3. {
4. if (fatal_fn) {
5. fatal_fn(errcode);
6. exit(errcode); /* should never be reached */
7. } else if (errcode == _EVENT_ERR_ABORT)
8. abort();
9. else
10. exit(errcode);
11. }

可以发现，这里也有一个fatal_fn，这里会先判断fatal_fn是否为空，如果为空，还会进一步判断errcode是否为_EVENT_ERR_ABORT，如果是_EVENT_ERR_ABORT，就会调用abort函数，向调用进程发送SIGABORT信号，使得进程异常退出，否则直接exit。

那么这个fatal_fn是什么东西呢？

错误处理回调函数指针fatal_fn

查看fatal_fn的相关定义，如下所示：

static event_fatal_cb fatal_fn = NULL;

其中的event_fatal_cb定义如下：

typedef void (*event_fatal_cb)(int err);

可见，这里的fatal_fn实际上和前面的log_fn是差不多的，初始化也是NULL。

设置错误处理回调函数event_set_fatal_callback

错误处理回调函数是通过event_set_fatal_callback进行设置的，其定义如下：

1. void
2. event_set_fatal_callback(event_fatal_cb cb) //指定错误处理回调函数
3. {
4. fatal_fn = cb;
5. }

与event_set_log_callback类似，直接传入函数名即可设置错误处理函数，若要恢复默认处理函数，就直接传入NULL即可。

日志及错误处理流程

实际上，对于libevent库的使用者来说，日志及错误处理内部如何实现是无需关心的，但是仍有两点需要注意：

libevent默认的日志处理行为是打印在终端屏幕，这往往不符合我们真正的需求。如果我们想按照自己的方式进行日志处理，那么就可以自定义一个日志处理函数（比如说将错误或警告信息输出到文件中），再将该函数名作为参数调用event_set_log_callback即可，如果想再恢复默认的日志处理行为，那么再次调用event_set_log_callback函数传入NULL即可。

另一点是错误处理，libevent的错误处理仅在发生error的时候进行，在进行错误处理之前会先进行日志处理，默认的错误处理行为是直接abort或者exit。如果想在发生错误后，程序退出之前做一些其他处理，那么就可以自定义一个错误处理函数，并将该函数名作为参数调用event_set_fatal_callback即可，如果想再恢复默认的错误处理行为，那么再次调用event_set_fatal_callback函数传入NULL即可。

不管是调用event_set_log_callback还是调用event_set_fatal_callback，都应该在error、warn、msg、debug等发生之前调用，因为一旦发生了各种情况，那么就会自动去调用日志和错误处理函数了， 因此应当提前设置好自定义的处理函数。