源码剖析signal和sigaction的区别[通俗易懂]

大家好，又见面了，我是你们的朋友全栈君。

这两个函数都是Linux下注册信号处理函数有关，但是它们的区别一般我们都是从书上、网上、man手册得知，要想对它们的区别了然于胸，源码剖析才是彻底的方法。先来看这两个函数的区别和实验：

一、实验

1、signal比sigaction简单，但signal注册的信号在sa_handler被调用之前把会把信号的sa_handler指针恢复，而sigaction注册的信号在处理信号时不会恢复sa_handler指针。所以用signal函数注册的信号处理函数只会被调用一次，之后收到这个信号将按默认方式处理，如果想一直处理这个信号的话就得在信号处理函数中再次用signal注册一次，一般都在信号处理函数开始处调用signal注册一次这个信号，虽然这样可以一直能处理这个信号，但是可以看出，在sa_handler指针恢复到再次调用signal注册信号期间如果收到这个信号，那么这个信号就按默认方式处理，如果是INT之类信号的话，进程就可能退出了，虽然有这种概率，但还是非常非常小的。更好的做法是：除了SIG_IGN、SIG_DFL之外，最好用sigaction来代替signal注册信号。

实验一：

signal_int_handler.c：

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <signal.h>

void sigint_handler(int signo)
{
    //signal(signo, sigint_handler);
    printf("sigint_handler, signo: %d\n", signo);
}

int main(int argc, char *argv[])
{
    signal(SIGINT, sigint_handler);

    while (1) {
        printf("sleep 2s\n");
        sleep(2);
    }

    return 0;
}

代码很简单，就是用signal注册SIGINT信号处理函数为sigint_handler，sigint_handler也只是打印一条信息而已，编译运行：

源码剖析signal和sigaction的区别[通俗易懂]
图中显示的^C就是我用键盘ctrl+c发出去的信号打印出来的，可见发了5次SIGINT信号，sigint_handler函数也执行了5次，好像signal注册的信号处理函数并不恢复成默认值，但是……请先看下面的实验二。

实验二：

代码还是跟上面的实验一一样，只是编译参数加一个-std=c99，编译运行：

如图所示，发送了两次SIGINT信号，第一次被sigint_handler函数处理了，第二次时进程就退出了（因为SIGINT信号的默认行为就是进程退出），从现象上看，SIGINT信号处理函数被恢复了。

实验一和实验二只是一个编译参数的区别，为什么一个恢复了信号处理函数，一个没有恢复呢，原因稍后揭开。

实验三：

sigaction_int_handler.c：

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <signal.h>

void sigint_handler(int signo)
{
    printf("sigint_handler, signo: %d\n", signo);
}

int main(int argc, char *argv[])
{
    struct sigaction sa;

    sa.sa_handler = sigint_handler;
    sigemptyset(&sa.sa_mask);

    if (sigaction(SIGINT, &sa, NULL) == -1) {
        perror("sigaction:");
    }

    while (1) {
        printf("sleep 2s\n");
        sleep(2);
    }

    return 0;
}

代码与实验一的区别只是改用sigaction来注册信号处理函数，编译运行：

可以看出结果与实验一一样，并没有恢复信号处理函数到默认值，因为是用sigaction注册的，所以也是意料之中。

实验四：

同实验二一样，加一个编译参数-std=c99编译结果如下：

编译出错了，可能是struct sigaction并不在c99编译条件里面。这种情况就不管了。

2、signal在调用sa_handler过程中不支持信号block；sigaction在调用sa_handler之前会先将该信号block，sa_handler执行完成之后再恢复。

实验五：

signal_int_handler_block.c：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <signal.h>

void sigint_handler(int signo)
{
    signal(signo, sigint_handler);
    printf("sigint_handler, signo: %d, pid: %d\n", signo, getpid());

    printf("sleep 10s\n");
    sleep(10);
    printf("sigint_handler done\n");
}

int main(int argc, char *argv[])
{
    int i, ret;
    pid_t pid;

    signal(SIGINT, sigint_handler);

    printf("start\n");

    if ((pid = fork()) == 0) {
        //children
        sleep(1);
        for (i = 0; i < 5; i++) {
            ret = kill(getppid(), SIGINT);
            printf("child, pid: %d, ppid: %d, ret: %d\n", getpid(), getppid(), ret);
        }
        exit(0);
    } else if (pid < 0) {
        perror("fork error: ");
        exit(1);
    }

    //parent

    while (1) {
        printf("sleep 2s\n");
        sleep(2);
    }

    return 0;
}

上面这段代码原理是：主进程用signal注册SIGINT信号处理函数——sigint_handler，这个函数在处理信号时用sleep阻塞10s才返回，主进程fork出一个子进程，这个子进程向主进程发送5次SIGINT信号后退出，编译运行结果如下：

从图中可见，子进程成功发送了5次SIGINT给父进程（图中第一个白色方框所示），父进程打印了两次sigint_handler done（图中前两个红框所示），你可能会问为什么只打印两次而不是5次？这是因为第2次信号被阻塞了，还没得到处理，那第3、4、5次的信号就跟第2次信号一样，反正等着进程来执行处理函数就行了，内核的实现就是在给进程发送信号时，如果进程还有该信号等待处理，那后发的信号就什么都不做就返回了。接着我用键盘ctrl+c连续发送5次SIGINT信号（图片第二个白色框所示^C），然后父进程也能接顺序处理。可以看出signal能block信号，并在调用完信号处理函数后接着处理之前block的信号。那与signal不支持信号block信号不是矛盾吗？再来看看加了-std=c99编译参数之后的结果：

实验六：

加上-std=c99参数效果就跟实验五不一样了，信号处理函数sigint_handler在收到信号时就直接执行，并没有等上一个信号处理完了再处理下一个信号，也就是说没有block信号。原因也是稍后揭晓。

实验七：

sigaction_int_handler_block.c：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <signal.h>

void sigint_handler(int signo)
{
    printf("sigint_handler, signo: %d, pid: %d\n", signo, getpid());

    printf("sleep 10s\n");
    sleep(10);
    printf("sigint_handler done\n");
}

int main(int argc, char *argv[])
{
    int i, ret;
    pid_t pid;
    struct sigaction sa;

    sa.sa_handler = sigint_handler;
    sigemptyset(&sa.sa_mask);

    if (sigaction(SIGINT, &sa, NULL) == -1) {
        perror("sigaction:");
    }

    printf("start\n");

    if ((pid = fork()) == 0) {
        //children
        sleep(1);
        for (i = 0; i < 5; i++) {
            ret = kill(getppid(), SIGINT);
            printf("child, pid: %d, ppid: %d, kill ret: %d\n", getpid(), getppid(), ret);
        }
        exit(0);
    } else if (pid < 0) {
        perror("fork error: ");
        exit(1);
    }

    while (1) {
        printf("sleep 2s\n");
        sleep(2);
    }

    return 0;
}

这个实验是用sigaction来替换signal，原理上讲sigaction是可以block信号的，看看编译运行结果：

可以看出，结果与实验五是一样的，这也是意料之中。

3、sigaction控制粒度更细，可以设置sigaction里面的sa_mask、sa_flags，比signal支持更多功能，可参考man，这里实验就免了。

从上面的区别以及实验结果可以看出，signal有时跟sigaction一样，有时又不一样，这又是什么原因呢。下面来看看上面的种种疑惑吧。

分别用strace跟踪一下实验一和实验二的二进制程序：

可以看出signal是调用rt_sigaction来实现的（上图红框所示），上面这两个图的主要区别是rt_sigaction函数第二个参数的标志位，不加-std=c99时为：SA_RESTORER|SA_RESTART，加-std=c99时为：SA_RESTORER|SA_INTERRUPT|SA_NODEFER|SA_RESETHAND，其中主要关注这两个标志：SA_NODEFER|SA_RESETHAND，SA_RESETHAND这个标志是导致实验一与实验二有区别的原因，SA_NODEFER是导致实验五和实验六有区别的原因，简单来说SA_RESETHAND就是用来恢复sa_handler的，SA_NODEFER是用来标志是否block信号的。

也来看看实验三的strace结果：

可以看出sigaction也是调用了rt_sigaction系统调用函数来实验的，它的标志没有SA_NODEFER|SA_RESETHAND，所以它处理信号时并没有恢复sa_handler，而且可以block信号。

二、信号安装

既然signal和sigaction最终都是调了系统调用rt_sigaction，那就得剖析一下rt_sigaction源码是怎么实现的了：

上面代码中，rt_sigaction主要是调用do_sigaction来安装信号，do_sigaction也是主要把老信号信息保存到oact然后在current->sighand->action中安装新信号信息（上面红框代码所示第3105行和第3110行）。

其实内核里也有signal系统调用函数，如下图所示，它注释里也说是为了向后兼容，功能已被sigaction取代了，不过可以看到第3531行中，它的默认标志是SA_ONESHOT|SA_NOMASK，其中SA_ONESHOT就是SA_RESETHAND（因为：#define SA_ONESHOT SA_RESETHAND），最后也是调用do_sigaction来安装信号：

三、信号处理

这里只讲一下与上面实验有关的关键函数。信号处理大体流程关键代码如下：

void
ia64_do_signal (struct sigscratch *scr, long in_syscall)
{
	struct k_sigaction ka;
……
	while (1) {
		int signr = get_signal_to_deliver(&info, &ka, &scr->pt, NULL);//获取信号
……
		if (handle_signal(signr, &ka, &info, scr))//处理信号
			return;
……
	}
……
｝

其中get_signal_to_deliver的关键代码是：

第2263行是从current中获取当前进程被block的信号索引，然后第2274行从信号向量中获取信号的处理函数结构，第2279行到第2289行也比较明了，关键是第2285、2286行，如果标志打上SA_ONESHOT，那就将sa_handler恢复成SIG_DFL，这也是实验二第二次收到信号的时候就退出的原因。

再来看看handle_signal以及它调用的signal_delivered函数：

handle_signal主要是调用setup_frame为信号处理函数准备执行环境和调用signal_delivered来更新blocked信号。从第2402行可以看出如果sa_flags没有打上SA_NODEFER标志则把这个信号添加到blocked信号向量中。这就是实验六没有block信号的原因。

最后，至于在应用程序中调用signal为什么到内核就变成了rt_sigaction了呢，也大概说一下吧：

反汇编一下实验一和实验二的二进制程序（dis是我写的一个反汇编程序指定函数的shell命令，可以在我之前博客中找到），可以发现它们分别调了signal和__sysv_signal这两个函数，这两个函数应该是glibc里面的。grep一下就找到了它们的源码了：