一. 前言

Linux/UNIX进程信号处理复杂易出错，而用在多线程中就更加复杂脆弱，这里不探讨相关历史渊源，只给出一种在实践中简单可靠的信号处理方式。后文讨论的线程模型是POSIX thread(pthread)，Linux和主流UNIX均支持pthread。

二. 进程与线程信号模型

这里假设读者已熟悉进程信号模型，下面列出多线程环境中，信号模型的进一步细节：

1. 信号action属于进程级别。忽略信号action /  默认action(可能core dump) / 自定义action，所有线程共享该action。

2. 信号递交到进程时，内核会任选一个线程来处理，只有下面三种情况才会由特定线程处理：信号源于线程执行了特定硬件指令，如SIGBUS / SIGFPE / SIGILL / SIGSEGV。线程写一个关闭读端或出错的流式管道，触发SIGPIPE，常见于pipe / FIFO / UNIX domain socket / TCP socket。pthread_kill和pthread_sigqueue所发出信号。

3. 信号mask属于线程级别，可以通过pthread_sigmask来控制。

4. 信号pending属于线程级别，可由sigpending获取。

三. 可重入(re-entrant)函数 / 线程安全(thread-safe)函数 / 异步信号安全(async-signal-safe)函数

SUS有很长的列表规定了哪些不是线程安全函数，哪些是异步信号安全函数，但没必要记那个表格，只要对分类原理有深入理解，必要时才查标准或手册。下面列出一些关键点：

1. 可重入是一个理论概念，可以理解为给定的输入能得到确定性输出，不能是随机或undefined行为，实践中需要有上下文环境。在异步信号执行中，可重入意味着异步信号安全。在多线程执行中，可重入意味着线程安全。

2. 异步信号安全，同一个线程或不同线程，同步执行或异步执行，都能保证安全性。这在系统调用和库函数中属于少数派，所以SUS详细列出了这些函数。IO系统调用open/close/read/write属于此类；标准IO函数fopen / fclose / fread / fwrite / printf等等则不属于此类。一般修改共享数据结构意味着异步信号不安全，比如标准IO函数；不过有例外，存取sig_atomic_t，gcc支持的硬件架构中存取1/2/4/8字节的整数类型，更广义的就是最新C/C++标准支持的atomic系列函数，这些都是异步信号安全的。

3. 线程安全，可供多个线程安全调用的函数，包括异步信号安全函数。这个门槛不高，多数系统调用和库函数都满足，所以SUS只规定了哪些函数不必是线程安全的。标准IO函数属于此类，malloc / free也是，它们虽然使用了全局数据结构，但是内部有互斥锁，可以保证安全性，localtime则不是，它用了静态数据结构，内部没有锁保护，标准有localtime_r替代，’xxx_r’是一大类线程安全的函数，具体可以查文档。修改共享数据结构却没有锁保护，意味着线程不安全。

四. 运行环境

Linux: kernel 3.12 / gcc 4.8

UNIX: mac os x 10.9 / llvm 3.4

五. 一个常见的错误

很多人在信号处理函数中经常写一堆printf，几十行的demo还行，但实际项目中就是一个风险，可能出错的终将出错，往往关键时刻掉链子。下面就构造一个稍极端的例子演示会发生什么。

C源码：

点击(此处)折叠或打开

#include

#include "lgr_hdr.h"

static void handler(int sig)

{

printf("this is handler\n");

}

int main(int argc, char **argv)

{

struct sigaction sa;

sigemptyset(&sa.sa_mask);

sa.sa_flags = 0;

sa.sa_handler = handler;

if (sigaction(SIGUSR1, &sa, NULL) == -1)

err_sys("sigaction");

while (1) {

printf("this is main\n");

}

return 0;

}

构造错误场景的步骤：

1. 启动C程序。

bash-4.2 $./async_signal | grep -F handler

2. 用Python解释器每隔10毫秒，向C程序发送一个SIGUSR1，直到C程序停止输出内容。

bash-4.2 $ps -ef|grep async

lgr 1108 945 99 17:37 pts/0 00:00:25 ./async_signal

bash-4.2 $python

Python 2.7.5 (default, Feb 19 2014, 13:47:40)

[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> import os, time

>>> for i in range(2000):

... os.kill(1108, 10)

... time.sleep(0.01)

... 3. 利用strace看进程当前系统调用，发现进程是死锁状态。上面这几个步骤在mac os x 10.9也可以重现，不过要用dtrace看系统调用。

bash-4.2 $strace -p 1108

Process 1108 attached

futex(0x43324880, FUTEX_WAIT_PRIVATE, 2, NULL

问题原因：

在Linux下标准IO内部通过pthread(NPTL)实现线程安全，而同步原语用futex实现，printf访问的stdout是一个全局数据结构，必须由互斥锁来保护，如果进程执行锁保护的代码过程中被信号中断，而信号处理函数恰好也调用printf，意味着互斥锁没有被解锁的情况下再次加锁，死锁是必然的。上面的例子是一个单线程，我测试时只发送了不到2000个信号就触发了死锁，如果是多个线程，死锁可能性将大大提高。

六. 简单可靠的信号处理方式

原则上信号处理函数尽量简单。一个解决办法就是在信号处理函数中只使用异步信号安全函数，理论上是没问题，但实现起来可能比较费劲，snprintf / write远不如printf简单明了。另一个办法就是本文推荐的同步处理方式。

原理：

每个线程都有独立的信号mask，给定一组我们感兴趣的信号，主线启动时用pthread_sigmask阻塞该组信号，意味着后续启动的所有线程都继承了主线程的mask，然后新创建一个线程调用sigwait，该信号处理线程调用sigwait是同步等待，所以信号处理函数内部只需要保证线程安全，大大降低实现复杂度。

C实现源码：

点击(此处)折叠或打开

static struct sigaction th_sa;

static void *th_signal_handler(void *arg)

{

int sig;

struct sigaction *sa = arg;

while (1) {

if (sigwait(&sa->sa_mask, &sig) != 0) {

err_ret("sigwait");

break;

}

sa->sa_handler(sig);

}

return NULL;

}

int register_signal_handler(int *sigset, int num, sig_t handler)

{

pthread_t tid;

int i;

int ret;

sigemptyset(&th_sa.sa_mask);

th_sa.sa_handler = handler;

for (i = 0; i < num; ++i) {

sigaddset(&th_sa.sa_mask, sigset[i]);

}

ret = pthread_sigmask(SIG_BLOCK, &th_sa.sa_mask, NULL);

if ( ret != 0) {

err_ret("pthread_sigmask");

return -1;

}

ret = pthread_create(&tid, NULL, th_signal_handler, &th_sa);

if (ret != 0) {

err_ret("pthread_create");

return -1;

}

return 0;

}

使用方法：

点击(此处)折叠或打开

static void handler(int sig)

{

printf("this is handler\n");

}

int main(int argc, char **argv)

{

int sigset[] = {SIGUSR1};

if (register_signal_handler(sigset, ARRAY_SIZE(sigset), handler) == -1)

err_quit("register_signal_handler");

while (1) {

printf("this is main\n");

}

return 0;

}