muduo库学习之C++多线程系统编程精要07——多线程与 fork、多线程与signal

东阳的学习笔记

1. 多线程与 fork

多线程与 fork() 的协作性很差。这是 POSIX 系列操作系统的历史包袱。

1.1 fork 一般不能在多线程程序中使用

因为 Linux 的 fork() 只克隆当前线程的 thread of control,不克隆其他线程。fork() 之后,除了当前线程之外的所有线程都消失了。

forkall() 是很难办到的。因为其他线程可能等在 condition variable 上面,可能阻塞在系统调用上、可能等着 metux 以进入临界区

1.2 fork() 之后的子进程可能陷入无法调用的境地

  • fork()之后子进程中 只有一个线程,其他线程都消失了,这就造成一个危险的局面:

    • 其他线程可能正好位于临界区之内,持有了某个锁, 而它突然死亡,再也没有机会去解锁了
    • 如果子进程试图再对同一个mutex加锁,就会立刻死锁
  • 在fork()之后,子进程就相当于处于signal handler之中,你不能调用线程安全的函数(除非它是可重入的),而只能调用异步信号安全(async-signal-safe)的函数

  • 比方说,fork()之后,子进程不能调用:

    • malloc。因为malloc()在访问全局状态时几乎肯定会加锁
    • 任何可能分配或释放内存的函数,包括new、map::insert()、 snprintf(在浮点数转换为字符串时有可能需要动态分配内存)……等等
    • 任何Pthreads函数。你不能用pthread_cond_signal()去通知父进程, 只能通过读写pipe来同步(见http://github.com/chenshuo/muduo-protorpc中Zurg slave示例的Process::start())
    • printf()系列函数。因为其他线程可能恰好持有stdout/stderr的锁
    • 除了man 7 signal中明确列出的“signal安全”函数之外的任何函数

1.3 唯一安全的做法是 fork() 加 exec()

这样会彻底断绝子进程与父进程的联系

2. 多线程与 Singal

在多线程程序中,使用 singal 的第一原则就是不要使用 Singal

2.1 处理信号是一件棘手的事

  • 在单线程时代:
    • **编写信号处理函数就是一件棘手的事情,**由于signal打断了正在运行的thread of control
    • 在signal handler中只能调用async-signal-safe的函数(http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03),即所谓的“可重入(reentrant)”函数,就好比在DOS时代编写中断处理例程(ISR)(http://en.wikipedia.org/wiki/Interrupt_handler)一样。不是每个线程安全的函数都是可重入的(见上面“二”中举的例子)
    • 还有一点,如果signal handler中需要修改全局数据,那么被修改的变量必须是sig_atomic_t类型的(http://www.gnu.org/software/libc/manual/html_mono/libc.html#Atomic-Data-Access)。否则被打断的函数在恢复执行后很可 能不能立刻看到signal handler改动后的数据,因为编译器有可能假定这个变量不会被他处修改,从而优化了内存访问
  • 在多线程时代:
    • signal的语义更为复杂。信号分为两类:
      • 发送给某一线程(SIGSEGV)
      • 发送给进程中的任一线程(SIGTERM)
    • 还要考虑掩码(mask)对信号的屏蔽等
    • 特别是在signal handler中不能调用任何Pthreads函数,不能通过condition variable来通知其他线程

2.2 在多线程程序中,使用 singal 的第一原则就是不要使用 Singal

  • 不要用signal作为IPC的手段,包括不要用SIGUSR1等信号来触发服务端的行为。如果确实需要,可以用后面的“构建易于维护的分布式程序”文章中介绍的增加监听端口的方式来实现双向的、可远程访问的进程控制
  • **也不要使用基于signal实现的定时函数,**包括 alarm/ualarm/setitimer/timer_create、sleep/usleep等等
  • 不主动处理各种异常信号(SIGTERM、SIGINT等等),只用默认语义:结束进程
    • 有一个例外:SIGPIPE,服务器程序通常的做法是忽略此信号,否则如果对方断开连接,而本机继续write的话,会导致程序意外终止
    • 在命令行程序中,默认的SIGPIPE行为非常有用。例如查看日志中的前10条错误信息,可以用管道将命令穿起来:gunzip -c log.gz | grep ERROR | head,由于head关闭了管道的写入端,grep会遇到SIGPIPE而终止,同理gunzip也就不需要解压缩整个巨大的日志文件。这也可能是Unix默认使用阻塞IO的历史原因之一
  • 在没有别的替代方法的情况下(比方说需要处理SIGCHLD信 号),把异步信号转换为同步的文件描述符事件。传统的做法是在 signal handler里往一个特定的pipe写一个字节,在主程序中从这个pipe读取,从而纳入统一的IO事件处理框架中去。现代Linux的做法是采 用signalfd(2)把信号直接转换为文件描述符事件,从而从根本上避免使 用signal handler(例子见http://github.com/chenshuo/muduo-protorpc中Zurg slave示例的ChildManager class)

你可能感兴趣的:(muduo网络库)