Tor源码分析五 -- 客户端执行流程（libevent调度）

　　上一源码分析的小节中，已经将系统的主要流程启动过程介绍完毕。实际上，系统在如此启动之后，就可以通过正确的流程将Tor系统完整的启动起来，为用户提供应用程序代理服务，以达到匿名通信的目标。本节的目标，不是为了详细介绍系统初始化后的正确启动流程，而是介绍系统是如何通过Libevent的调度实现成功启动的。也就是说，本节的重点在于说明Libevent调度机制在Tor系统之中的应用。

　　上节当中也简要介绍了Libevent的三种应用方式：信号处理；定时处理；网络套接字处理。这三种处理内容对于Libevent来说均是事件，只是事件的属性与回调函数不同而已。Libevent根据自身的调度机制，优先级队列等，来进行事件的调度。事件大多在被创建之时就被加入到Libevent事件集之中，Libevent一旦发现事件被激活，就会执行事件相应的回调函数。而值得说明的是，激活事件的方式根据事件类别的不同而有所区别：

　　1）signal - 信号处理事件：挂起的信号处理事件在进程接收到相应信号时被激活，信号的发送者可以是用户，也可以是另外一个进程等；

　　2）time - 定时处理事件：挂起的定时处理事件在定时器到时时被激活，定时器的时间设定会在定时处理事件生成时就指定；

　　3）socket - 网络套接字处理事件：挂起的网络套接字处理事件主要分两种，分别为读事件和写事件；读事件在相应套接字有数据可读时被激活；写事件比较特殊，它总是处于激活状态的，也就是说，只要套接字是正常可写的，写事件就会不断被激活；因为写事件的情况特殊，所以Tor系统对其的处理是动态地增删，而不是像读事件一样一直放置于事件池内部。利用Libevent的事件池输出调试函数event_base_dump_events可以看到事件池内事件的变动和简单状态，是调试Tor系统的重要手段。（我们讨论非阻塞的读写事件，若读写事件是阻塞的，则Tor系统的单线程执行很容易就会被阻塞，系统就无法正常运行）

0. 系统中的普通事件

　　此处暂且介绍客户端系统的事件集，服务器端的事件集可以由此作为依据进行猜测。

　　0.1. 监听事件(socket)  -- 系统初始化阶段 tor_init()

　　客户端系统中的监听事件主要分为两种：socket监听；control监听。

　　以上两种监听事件的目的是不同的：socket监听是监听Tor提供给用户程序的应用端口，接收的是应用请求；control监听是监听Tor提供给用户的控制端口，通过向控制端口传送相应的命令，可以有效控制Tor系统的执行，该部分的控制规则可以在文件control-spec.txt中找到详细的说明。

　　监听事件的添加是在监听连接创建之后马上执行的，主要处理代码在初始化阶段，入口函数为options_act_reversible。其后主要是通过connection_listener_new函数中的处理来完成事件的新建和添加。connection_start_reading函数完成了事件向事件集中添加的具体操作。在完成了添加之后，一旦进入到主循环的Libevent循环，就将控制权交给Libevent，通过Libevent的机制进行调度，执行提供的回调函数。

　　此处值得先一提的是，对于所有连接的读事件和写事件，执行的回调函数分别相同：conn_read_callback，conn_write_callback。在后期的分析之中，会着重介绍这两个函数对网络套接字事件所执行的具体处理。

　　0.2. 信号事件(signal) -- 系统无限循环开启前 do_main_loop()

　　与大多数的Linux软件编程类似，Tor系统进程需要准确地控制进程以接收信号完成相应操作。信号的处理是件相对繁琐的事情，我们此处略去信号的具体处理细节，而把注意力集中在Tor系统是如何利用Libevent来进行信号控制。其实其过程也相对简单，只利用了一个函数：

/** Set up the signal handlers for either parent or child. */
void
handle_signals(int is_parent)
{
#ifndef _WIN32 /* do signal stuff only on Unix */
  int i;

  // 定义需要处理的信号
  static const int signals[] = {
    SIGINT,  /* do a controlled slow shutdown */
    SIGTERM, /* to terminate now */
    SIGPIPE, /* otherwise SIGPIPE kills us */
    SIGUSR1, /* dump stats */
    SIGUSR2, /* go to loglevel debug */
    SIGHUP,  /* to reload config, retry conns, etc */
#ifdef SIGXFSZ
    SIGXFSZ, /* handle file-too-big resource exhaustion */
#endif
    SIGCHLD, /* handle dns/cpu workers that exit */
    -1 };

  //信号事件集
  static struct event *signal_events[16]; /* bigger than it has to be. */

  if (is_parent) { // 父进程信号处理交由Libevent进行
    for (i = 0; signals[i] >= 0; ++i) {
      signal_events[i] = tor_evsignal_new(
                       tor_libevent_get_base(), signals[i], signal_callback,
                       (void*)(uintptr_t)signals[i]);
      if (event_add(signal_events[i], NULL))
        log_warn(LD_BUG, "Error from libevent when adding event for signal %d",
                 signals[i]);
    }
  } else { // 子进程信号处理由系统默认信号处理机制sigaction完成
    struct sigaction action;
    action.sa_flags = 0;
    sigemptyset(&action.sa_mask);
    action.sa_handler = SIG_IGN;
    sigaction(SIGINT,  &action, NULL);
    sigaction(SIGTERM, &action, NULL);
    sigaction(SIGPIPE, &action, NULL);
    sigaction(SIGUSR1, &action, NULL);
    sigaction(SIGUSR2, &action, NULL);
    sigaction(SIGHUP,  &action, NULL);
#ifdef SIGXFSZ
    sigaction(SIGXFSZ, &action, NULL);
#endif
  }
#else /* MS windows */
  (void)is_parent;
#endif /* signal stuff */
}

　　总的说来，上述函数执行完毕之后，系统会在Libevent事件列表中挂入信号处理事件。信号的处理从此就交由Libevent自动执行。具体是如何处理的，则需要进一步研究回调函数signal_callback。而这并不是本文的重点，所以此处略去。

　　0.3.定时事件(time) -- 系统无限循环开启前 do_main_loop()

　　Tor系统为了维护系统重要模块和组件，需要进行每秒一次的系统维护工作。同时，系统中的流量控制模块也需要进行定期的流量审查和令牌填充等操作。所以，定时事件是Tor系统必须要处理的重要事件。定时事件根据上面的描述，有主要分为两个：每秒一次的系统定时维护事件；定期的流量控制事件。

  /* set up once-a-second callback. */
  if (! second_timer) { //每秒执行的系统维护定时器事件
    struct timeval one_second;
    one_second.tv_sec = 1;
    one_second.tv_usec = 0;

    second_timer = periodic_timer_new(tor_libevent_get_base(),
                                      &one_s