Linux fd 系列｜信号编程（signal）竟能这样做？涨姿势

信号是什么？

平台声明：

Linux 操作系统

首先说，信号（signal）是什么？

信号（ signal ）本质是 Linux 进程间通信的一种机制，也叫软中断信号。既然是通信机制，那么就是传递信息用的，信号传递的信息很简单，就是一个整数，一般用于配合系统管理任务，比如进程的终结、恢复、热加载等。

信号都用整数常量表示，命名以 SIG 为前缀，比如 SIGINT（ ctrl-c 触发），SIGKILL（ kill -9 触发 ）。

信号一般怎么产生？

• 由内核产生，比如内存错误，除 0 等错误，内核通过信号通知到相应的进程；
• 可以由其他进程传递给目标进程，比如 kill 命令就是专门干这个事情的；

信号处理分为两个阶段：

• 发送阶段：内核将信号（signal）放到对应的 pending 队列中；
• 传递阶段：也叫做处理阶段，内核将信号从 pending 队列中取出来，并且进行处理，一般是调用相应的回调函数（处理方式有三种：用户定义、内核默认定义 SIG_DEL、忽略 SIG_IGN）；

signalfd 是什么？

了解了什么是信号（ signal ），那 signalfd 又会是什么呢？

是一个跟信号关联的文件描述符，能够以 io 的行为获取到系统信号，属性上来讲 signalfd 也是一个匿名 fd 类型。

signalfd 长什么样子？

奇伢按照 man signalfd 里面的例子，写了个 demo，跑在 Linux 机器上，按照惯例去看下 fd 的样子。

root@ubuntu:~# ll /proc/15445/fd

lrwx------ 1 root root 64 Aug 24 16:42 3 -> anon_inode:[signalfd]

root@ubuntu:~# cat /proc/15445/fdinfo/3 
pos: 0
flags: 02
mnt_id: 11
sigmask: 0000000000000006

从这里可以得到简单的信息：

1. signal 用的匿名 inode ，signalfd 属于匿名 fd 的一种；
2. 句柄关联的重要信息就是 sigmask，通过 /proc/${pid}/fdinfo/3 能看到这个值；

signalfd 使用姿势？

其实信号是很讲究的，甚至有信号编程一说，Linux 的 signalfd 为信号的处理提供了一种新的方法，统一到文件的 io 模式，契合一切接文件的理念。

系统调用：

#include <sys/signalfd.h>

int signalfd(int fd, const sigset_t *mask, int flags);

该系统调用返回一个整数类型 signalfd，这个句柄跟信号行为绑定，当发生信号的时候，句柄触发可读事件。

第一个参数也可以传入一个有效的信号 fd 的句柄，如果传入的是 -1 ，那么内核会自动创建一个新的 fd 。

完整的代码例子，在 Linux 机器上，通过 man signalfd 就可以获取到。

// 信号清零
sigemptyset(&mask);

// 添加信号到掩码集
sigaddset(&mask, SIGINT);
sigaddset(&mask, SIGQUIT);

// 设置该进程为对应的信号集的内容（当前已经的信号集合做并集、交集、覆盖）
// 这行代码才是真正的信号设置；
sigprocmask(SIG_BLOCK, &mask, NULL)

// 创建 signalfd 句柄（绑定信号）
sfd = signalfd(-1, &mask, 0);

for (;;) {
    // 读取 signalfd 数据（数据代表信号）
    s = read(sfd, &fdsi, sizeof(struct signalfd_siginfo));
    // ...
    // 信号的逻辑处理
}

上面的例子，signalfd 没有信号（没有可读事件）的时候会阻塞在 read 调用上，运行效果如下：

root@ubuntu:~/temp# ./a.out 
^CGot SIGINT
^CGot SIGINT
^CGot SIGINT

可以看到每一次 ctrl + c 触发的信号被捕捉到，并且打印出来。用文件 io 的方式来接收信号，牛。

怎么做到的呢？照例，我们浅析一下内核的代码，位于 fs/signalfd.c，这是一个很小的文件，正是这个文件完成了对信号“文件化”的封装。

上面最重要的两个调用：

1. sigprocmask ：设置当前进程的信号掩码，把 SIGINT，SIGQUIT 处理屏蔽掉，关闭内核默认行为；
2. signalfd ：获取到一个和信号关联的“文件”句柄；

signalfd 原理剖析

环境声明：

Linux 内核版本 4.19

1 signalfd

SYSCALL_DEFINE3(signalfd, int, ufd, sigset_t __user *, user_mask, size_t, sizemask)
{
    return do_signalfd4(ufd, &mask, 0);
}

static int do_signalfd4(int ufd, sigset_t *mask, int flags)
{
    struct signalfd_ctx *ctx;

    // 如果是 -1，内核创建；
    if (ufd == -1) {
        // 
        ctx->sigmask = *mask;
        // 获取一个匿名句柄；
        ufd = anon_inode_getfd("[signalfd]", &signalfd_fops, ctx, O_RDWR | (flags & (O_CLOEXEC | O_NONBLOCK)));
    } else {
        // 校验传入的句柄是否合法
        struct fd f = fdget(ufd);
        ctx = f.file->private_data;
        if (f.file->f_op != &signalfd_fops) {
            return -EINVAL;
        }   
        // 覆盖设置新的值
        ctx->sigmask = *mask;
        // 唤醒阻塞在当前进程的信号等待队列
        wake_up(&current->sighand->signalfd_wqh);
    }   
    return ufd;
}

看一下 signalfd 支持的接口调用：

static const struct file_operations signalfd_fops = { 
    .show_fdinfo    = signalfd_show_fdinfo,
    .poll       = signalfd_poll,
    .read       = signalfd_read,
    // ...
};

通过这个可以知道 signalfd 支持的特性：

• 支持 /proc/${pid}/fdinfo/xx 查看信息（ 对应 signalfd_show_fdinfo 函数 ）；
• 支持 read，close 调用 （ 对应 signalfd_read 函数 ）；
• 支持 poll 调用，支持 epoll 管理（ 对应 signalfd_poll 函数 ）；

2 signalfd_poll

这个函数做的事情非常简单，就是把等待对象挂到当前进程的信号结构的链表上。表头是：current->sighand->signalfd_wqh ，这个就有意思了，这里直接挂到当前进程的结构上。换句话说，唤醒也是自此表头开始。

回忆一下 timerfd ，是挂在 timerfd_ctx->wqh 的字段上。这里的差别是因为信号是对进程来说的。

3 signalfd_read

读一个 signalfd 的操作非常简单，主要逻辑：

1. 查看当前队列中是否有信号，有的话就取出来，填充到用户给的结构体中；
2. 如果句柄是阻塞类型的，在没有信号的时候，会切走 cpu，等到有信号的时候切回来。如果是非阻塞类型的，直接报错，返回 EAGAIN ；

简要的代码注释如下：

static ssize_t signalfd_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
{
    // read 数据的存放结构体
    siginfo = (struct signalfd_siginfo __user *) buf;
    do {
        // 取出信号队列中的一个信号，填充好 info 结构体
        ret = signalfd_dequeue(ctx, &info, nonblock);
        // 循环操作，填充用户指定个数的信号
        ret = signalfd_copyinfo(siginfo, &info);
        // ...
    } while (--count);
    return total ? total: ret;
}

static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, siginfo_t *info, int nonblock)
{
    // 取出一个信号
    ret = dequeue_signal(current, &ctx->sigmask, info);
    // 如果没有 pending 的信号，就看是否是非阻塞请求，非阻塞请求就报错跳出；
    // 阻塞请求就继续往后走

    // 把当前位置加入到信号唤醒地方（这样后续有信号的时候，能够立马切回来）
    add_wait_queue(&current->sighand->signalfd_wqh, &wait);
    for (;;) {
        // 取信号
        ret = dequeue_signal(current, &ctx->sigmask, info);
        // 判断是否还有 pending 的信号；
        if (signal_pending(current)) {
        }
        // 让出 cpu，调度切走
        schedule();
    }

    // 把当前进程从 signalfd_wqh 摘掉
    remove_wait_queue(&current->sighand->signalfd_wqh, &wait);
}

这里就能非常清晰的看到，进程有信号的时候，signalfd 句柄就是可读的。

signal 和 epoll 的配合

1 熟悉的 epoll_ctl

epoll_ctl 注册 signalfd 的时候，调用 signalfd_poll ，signalfd_poll 会把 epoll 创建的 wait entry 挂到 current->sighand 上。唤醒的时候调用这个 wait 链表的回调。

2 什么时候唤醒呢？

唤醒的操作其实不在 signalfd.c 文件中，而是在原有的信号软中断的流程中。

在内核函数 signalfd_notify 中，会判断进程的 sighand->signalfd_wqh 是否非空，如果非空，说明有人关注这个信号，那么就会通知到对应的 waiter 。

为了知识的完整性，说个点，signalfd_notify 其实在 timer 定时器的流程中也有调用，但跟我们本次主干没啥关系，这里忽略。

信号的发送唤醒的简要示意图：

所有的信号发送都会调用到 send_signal ，在这个里面实现了唤醒 sighand->signalfd_wqh 链表的操作。从而使得 epoll 感知到 signalfd 可读了（因为来信号了），使得 epoll 从 epoll_wait 出唤醒，然后调用 read 操作，把信号的相关信息从句柄中读出来。

signalfd_notify
    -> wake_up （唤醒等待队列，也就是 epoll）
        -> ep_poll_callback

划重点：唤醒在信号发送的过程。

总结

1. 信号能够像文件一样 read 出来，这种优雅的信号处理方式得益于 signalfd 的封装；
2. 信号是挂在在进程 task_struct 结构体上的，信号队列非空的时候 signalfd 句柄可读；
3. 和 epoll 池的配合同样还是老套路，epoll_ctl 注册的时候调用 .poll 接口挂载 epoll 的 wait entry 到 sighand->signalfd_wqh 之上，信号发送时调用 signalfd_notify 唤醒 epoll ；
4. signalfd 也是一种匿名 fd 类型；

后记

一切皆文件，又学到一个句柄类型。