————————————————————————————————————————————————————————————————————————————————————
init_logging()（ or-0.3.1.8srccommonlog.c）内部逻辑如下图所示：
它的任务是初始化 tor 使用的全局日志设施；它首先检测并初始化用于保护日志信息和日志文件的互斥锁（log_mutex），它是一个 tor_mutex_t 对象
—— 请复习前一篇的相关讨论——具体方式为：
判断相同源文件内的全局变量 log_mutex_initialized 的值—— 0 代表日志互斥锁尚未初始化，那么它就调用 tor_mutex_init()
；显然，实际负责初始化 log_mutex 的是 pthread 库例程 pthread_mutex_init() 、并且把状态标记 log_mutex_initialized 置 1 。
涉及到的全局变量如下图：
接下来，它检查一枚全局的 smartlist_t 指针—— pending_cb_messages（基于 CallBack 的日志消息队列）——若该指针为 NULL 则
调用 smartlist_new()（ or-0.3.1.8srccommoncontainer.c）来初始化它。
然后检查传入的实参——若为 1，表明禁用启动消息队列，它就把全局变量 queue_startup_messages 修改为 0，意味着在等待配置日志的过程中不保
存消息；事实上，tor_main() 中为该实参传入 0 指示消息应该在早期就记录下来，如下图：
这种情况下，它再次调用 smartlist_new()来分配构建一个 smartlist_t 结构指针并赋给全局变量 pending_startup_messages，用于
处理启动时刻日志消息队列。pending_startup_messages 指向的各类启动消息（待输出）会在日志系统初始化完毕后重新播放出来。
涉及到的全局变量如下图：
如果你已经头晕了，那么我们就梳理一下目前为止讨论到全局变量和用途吧：
log_mutex—— 保护日志文件和消息的互斥锁；
log_mutex_initialized—— log_mutex 是否初始化；
pending_cb_messages—— 一枚 smartlist_t 指针（smartlist_t*），存储基于 CallBack 的日志消息队列，可用 smartlist_new() 初始化它；
pending_startup_messages—— 一枚 smartlist_t 指针，存储启动时刻日志消息队列，可用 smartlist_new() 初始化它；
queue_startup_messages—— 启动时刻是否记录日志消息；
disable_startup_queue—— init_logging() 的形参，调用者借助它来开启或关闭启动时刻消息队列功能；
init_logging() 内部逻辑如下图所示：
tor 实现了一种容量可调整、可存储任意数据类型的智能链表——smartlist，它由结构体 smartlist_t
（ or-0.3.1.8srccommoncontainer.h）来表示。“container”亦即容器，该模块抽象了许多数据结构来当成容器，
smartlist 只是其中之一。
smartlist_t 内有一个指针数组（list），每个元素（void*）可以指向任意类型的数据，且元素数量可调整，这就是它叫智能链表的原因
，如下图：
注释里写得很清楚：list 数组的大小可调整，调整后需要更新 capacity 字段（当前容量上限）；
num_used 字段记录当前元素数，这些元素（void*）指向有效的数据。你需要意识到一点—— 在 num_used 小于等于 capacity 时，
list 的大小不变；num_used 大于 capacity 时，list 就会动态扩展，同时更新 num_used 和 capacity。
对 smartlist_t 的操作由一些精心编写的例程实施，它们都以 smartlist_ 为前缀，其它模块函数无需知晓智能链表的内部细节，
只需调用这些例程来保证安全、正确地使用智能链表即可，这再次体现出数据抽象和封装、以及接口暴露。。。等高级 C 编程技巧！
这些 smartlist 例程原型如下图所示，分析它们的内部逻辑有助于深入理解智能链表的设计思想：
smartlist_new() 在堆中分配一块内存用于 smartlist_t 结构，然后返回一枚指向该内存块的指针，如下图所示：
可以看到，实际的分配函数是 tor_malloc()，后者封装了系统库函数 malloc()，并实现 tor 自己的安全分配算法；分配的内存大小
亦即结构体 smartlist_t 的大小（应该是 12 字节），该值在编译阶段计算出来。在返回一枚 smartlist_t 指针前，它还会将 num_used 字段设置为零，
表示尚未加入元素；将 capacity 字段设置为 SMARTLIST_DEFAULT_CAPACITY 宏定义的常量值（16），表示初始的容量上限为 16 枚
void 指针（总大小为 16 * 4 = 64 字节）；接下来它就会调用 tor_calloc() 实际分配另一块 64 字节大小的堆内存，用于
存储那些 void 指针，并让 list 字段持有该内存块的地址。smartlist_new() 返回后的堆内存布局如下图所示：
我在后面分析其它 smartlist_*() 辅助例程时，会将此图扩展以解释它们的作用。
smartlist_free() 销毁一个智能链表，但它并未实际释放堆中分配的 smartlist_t 结构与 void* 数组占据的内存，如下图：
smartlist_free() 通过调用 tor_free() -> raw_free() -> free() 把传入的 smartlist_t 指针置 NULL 后返回，因此它不会回收
相关的堆内存，如下图所示：
smartlist_add() 往智能链表（void* 数组）内加入新元素。
它首先调用 smartlist_ensure_capacity()，检查当前的容量上限是否允许加入，否则会先动态调大这个 void* 数组的容量后再把新元素
追加到尾部。如下图所示：
注意，它在调用 smartlist_ensure_capacity() 的同时就会通过一枚 smartlist_t 指针递增 num_used 字段值（寓意追加后的
元素数），然后在 smartlist_ensure_capacity() 内部会检查追加后的元素数是否超出当前容量上限，并采取相应措施！
smartlist_ensure_capacity() 处理完毕后，就可以确保作为数组下标的表达式 sl->list[sl->num_used++] 访问到的目标元素在
许可范围内，它被初始化为一枚新的 void 指针，语法解析如下图所示：
假设当前元素数已达初始上限（num_used = capacity = 16），相关的堆内存智能链表布局如下图：
执行 smartlist_add() 调用后的堆内存智能链表布局如下图：
由此可见，smartlist_ensure_capacity() 会按照 2 次幂来扩展 void* 数组的当前容量上限，而 smartlist_add() 在扩展部分
的起始地址处追加元素，扩展部分的其余元素为 NULL，留待后续使用。
现在让我们深入 smartlist_ensure_capacity() 内部研究它的堆内存分配算法，这种每次以 2 的幂扩展的机制在某种程度上类似于
OS 的内核内存分配算法简化版！如下图所示：
smartlist_ensure_capacity() 逻辑要点：
① 它是一个内联（inline）例程，这意味着在编译阶段，编译器会直接将其插入到调用者函数的内部，换言之，当我们反汇编
smartlist_add() 时，不会看到类似“call smartlist_ensure_capacity”这种指令，因为后者的逻辑已经被硬编码至前者内部，
这能够减少函数调用、返回时的栈帧创建、销毁等性能开销！
② 它的第二个参数类型为 size_t（亦即 unsigned int），这是一种安全表示长度、大小的类型（无负值），如前所述，
smartlist_add() 会为该参数传入递增 1 后的值，而 smartlist_ensure_capacity() 会判断这个更新的值是否超出了 void* 数组
的当前上限；
③ 开头部分的一些条件编译块计算 OS/硬件平台支持的 void* 数组最大上限—— SIZE_MAX 定义在平台相关的 limits.h 头文件内，
如下图所示，该头文件位于 Visual Studio 安装目录的 include 子路径下，它的值取决于编译器，比如这里的 0xFFFFFFFF，
就是十进制的 4,294,967,295 ；同理，INT_MAX 的值计算为 2,147,483,647 ；
SIZEOF_VOID_P 的值在 32 位平台上为 4。
经过一系列的预计算，最终得出 MAX_CAPACITY（表示 void* 数组的最大上限，以“元素数”为单位）的值为
1,073,741,823 个元素（SIZE_MAX / (sizeof(void*)），也就是说，void* 数组最大到 4 GB。
④ 用到了 tor_assert() 检查追加后的元素数，当超过最大容量上限时，调用库函数 abort() 终止程序运行；
tor_assert() 在前一篇讲过了。
⑤ 如果追加后的元素数在当前容量上限许可内，smartlist_ensure_capacity() 直接返回，不做任何事，它的调用者
可以安心执行后续操作；如果追加后的元素数超出当前上限，则每次按照 2 的幂为倍数增大当前上限，直到能够容纳
追加后的元素数，并且将扩展部分的内存初始化为零，以供后续使用、还要更新 capacity 字段为新的上限。
在分析源码的算法时，往往言词描述显得苍白无力，还是看看下面这张我绘制的 smartlist_ensure_capacity() 内部逻辑吧，
是不是有点 OS 内核内存分配器的影子？
我们最后再分析一下 smartlist_ensure_capacity() 内部实际负责扩展内存的 tor_reallocarray()，
以及负责清零内存的 memset() 函数调用，作为对本篇的收场，如下图所示：
由此我们推测出 init_logging() 以及相关的组件使用 smartlist 来集中管理日志消息。
下一篇将分析第二个条件编译块前的函数调用——monotime_init()。
——————————————————————————————————————————————————————