Linux信号【保存-处理】

最新推荐文章于 2024-05-22 23:21:29 发布

养乌龟的小少年

最新推荐文章于 2024-05-22 23:21:29 发布

阅读量940

点赞数 23

分类专栏： linux 文章标签： linux 运维服务器

本文链接：https://blog.csdn.net/weixin_45476980/article/details/136371130

版权

linux 专栏收录该内容

20 篇文章 0 订阅

订阅专栏

前言：

信号从产生到执行，并不会被立即处理，这就意味着需要一种 “方式” 记录信号是否产生，对于 31 个普通信号来说，一个 int 整型就足以表示所有普通信号的产生信息了；信号还有可能被 “阻塞”，对于这种多状态、多结果的事物，操作系统会将其进行描述、组织、管理，这一过程称为信号保存阶段

1、再次认识信号

补充信号传递的相关概念

1.1、概念

信号传递过程：信号产生 -> 信号未决 -> 信号递达

信号产生（Produce）：由四种不同的方式发出信号
信号未决（Pending）：信号从产生到执行的中间状态
信号递达（Delivery）：进程收到信号后，对信号的处理动作
在这三种过程之前，均有可能出现信号阻塞的情况

信号阻塞（Block）：使信号传递 “停滞”，无论是否产生，都无法进行处理

信号递达后的三种处理方式：

SIG_DFL 默认处理动作，大多数信号最终都是终止进程
SIG_IGN 忽略动作，即进程收到信号后，不做任何处理动作
handler 用户自定义的信号执行动作

注意：

信号阻塞是一种手段，可以发生在信号处理前的任意时段
信号阻塞与忽略动作不一样，虽然二者的效果差不多：什么都不干，但前者是干不了，后者则是不干了，需要注意区分

1.2、感性理解

将 信号传递 的过程比作 网上购物

可以抽象出以下概念：

信号产生：在某某购物平台上下达了订单
信号未决：订单下达后，快递的运输过程
信号递达：快递到达驿站后，你对于快递的处理动作
信号阻塞：快递运输过程中堵车了

只要你下单了，你的手机上肯定会有物流信息（未决信息已记录），当快递送达后（信号递达），物流记录不再更新

而堵车是一件不可预料的事情，也就是说：在下单后，快递可能一会儿送达（没有阻塞），可能五天送达（阻塞 -> 解除阻塞），有可能永不送达，因为快递可能永远堵车（阻塞）

堵车也有可能在你下单前发生（信号产生前阻塞）

至于信号递达后的处理动作如何理解呢？

快递送达后，正常拆快递（默认动作）
快递送达后，啥也不干，就是玩（忽略）
快递送达后，直接把快递退回去（用户自定义）
当然，用户自定义的情况可以有很多种，也有可能是直接把快递扔了

综上，网购的整个过程可以看作信号传递过程，本文探讨的是信号保存阶段，即物流信息

1.3、在内核中的表示

对于传递中的信号来说，需要存在三种状态表达：

信号是否阻塞
信号是否未决
信号递达时的执行动作

在内核中，每个进程都需要维护这三张与信号状态有关的表：block 表、pending 表、handler 表

所谓的 block 表和 pending 表其实就是位图结构

一个整型 int 就可以表示 31 个普通信号（实时信号这里不讨论）

比如 1 号信号就是位图中的 0 位置处，0 表示未被阻塞/未产生未决，1 则表示阻塞/未决
对于信号的状态修改，其实就是修改位图中对应位置的值（0/1）
对于多次产生的信号，只会记录一次信息（实时信号则会将冗余的信号通过队列组织）

如何记录信号已产生 -> 未决表中对应比特位置置为 1 ？

假设已经获取到了信号的 pending 表
只需要进行位运算即可：pending |= (1 << (signo - 1))
其中的 signo 表示信号编号，-1 是因为信号编号从 1 开始，需要进行偏移
如果想要取消未决状态也很简单：pending &= (~(1 << (signo - 1)))
至于阻塞 block 表，与 pending 表一模一样

对于上图的解读：

SIGHUP 信号未被阻塞，未产生，一旦产生了该信号，pending 表对应的位置置为 1，当信号递达后，执行动作为默认
SIGINT 信号被阻塞，已产生，pending 表中有记录，此时信号处于阻塞状态，无法递达，一旦解除阻塞状态，信号递达后，执行动作为忽略该信号
SIGQUIT 信号被阻塞，未产生，即使产生了，也无法递达，除非解除阻塞状态，执行动作为自定义

阻塞 block 与未决 pending 之间并没很强的关联性，阻塞不过是信号未决的延缓剂

信号在产生之前，可以将其阻塞，信号在产生之后（未决），依然可以将其阻塞

至于 handler 表是一个 函数指针表，格式为：返回值为空，参数为 int 的函数

可以看看 默认动作 SIG_DEL 和 忽略动作 SIG_IGN 的定义

/* Type of a signal handler.  */
typedef void (*__sighandler_t) (int);

/* Fake signal functions.  */
#define SIG_ERR	((__sighandler_t) -1)		/* Error return.  */
#define SIG_DFL	((__sighandler_t) 0)		/* Default action.  */
#define SIG_IGN	((__sighandler_t) 1)		/* Ignore signal.  */

默认动作就是将 0 强转为函数指针类型，忽略动作则是将 1 强转为函数指针类型，分别对应 handler 函数指针数组表中的 0、1 下标位置；除此之外，还有一个错误 SIG_ERR 表示执行动作为出错

简单对这三张表作一个总结，task_struct 中存在：

block 表（位图结构）比特位的位置，表示哪一个信号；比特位的内容代表是否对应信号被阻塞
pending 表（位图结构）比特位的位置，表示哪一个信号；比特位的内容代表是否收到该信号
handler 表（函数指针数组）该数组的下标，表示信号编号；数组的特定下标的内容，表示该信号递达后的执行动作

1.4、sigset_t 信号集

无论是 block 表 还是 pending 表，都是一个位图结构，依靠 除、余 完成操作，为了确保不同平台中位图操作的兼容性，将信号操作所需要的位图结构封装成了一个结构体类型，其中是一个 无符号长整型数组

/* A `sigset_t' has a bit for each signal.  */

# define _SIGSET_NWORDS	(1024 / (8 * sizeof (unsigned long int)))
typedef struct
  {
    unsigned long int __val[_SIGSET_NWORDS];
  } __sigset_t;

#endif

注：_SIGSET_NWORDS 大小为 32，所以这是一个可以包含 32 个无符号长整型的数组，而每个无符号长整型大小为 4 字节，即 32 比特，至多可以使用 1024 个比特位

sigset_t 是信号集，其中既可以表示 block 表信息，也可以表示 pending 表信息，可以通过信号集操作函数进行获取对应的信号集信息；信号集的主要功能是表示每个信号的 “有效” 或 “无效” 状态

block 表通过信号集称为阻塞信号集或信号屏蔽字（屏蔽表示阻塞），pending 表通过信号集中称为未决信号集

如何根据 sigset_t 位图结构进行比特位的操作？

假设现在要获取第 127 个比特位
首先定位数组下标（对哪个数组操作）：127 / (8 * sizeof (unsigned long int)) = 3
求余获取比特位（对哪个比特位操作）：127 % (8 * sizeof (unsigned long int)) = 31
对比特位进行操作即可
假设待操作对象为 XXX
置 1：XXX._val[3] |= (1 << 31)
置 0：XXX._val[3] &= (~(1 << 31))
所以可以仅凭 sigset_t 信号集，对 1024 个比特位进行任意操作，关于位图结构的实现后续介绍

2、信号集操作函数

对于信号的产生或阻塞其实就是对 block 和 pending 两张表的增删改查

2.1、增删改查

对于位图的增删改查是这样操作的：

增：| 操作，将比特位置为 1
删：& 操作，将比特位置为 0
改：| 或 & 操作，灵活变动
查：判断指定比特位是否为 1 即可
比特作为基本单位，不推荐让我们直接进行操作，操作系统也不同意，于是提供了一批系统接口，用于对信号集进行操作

#include <signal.h>

int sigemptyset(sigset_t *set);	//初始化信号集
int sigfillset(sigset_t *set);	//初识化信号集
int sigaddset(sigset_t *set, int signum);	//增
int sigdelset(sigset_t *set, int signum);	//删
int sigismember(const sigset_t *set, int signum);	//查

这些函数都是 成功返回 0，失败返回 -1

至于参数，非常简单，无非就是 待操作的信号集变量、待操作的比特位

注意： 在创建信号集 sigset_t 类型后，需要使用 sigemptyset 或 sigfillset 函数进行初始化，确保信号集是合法可用的

2.2、sigprocmask

sigprocmask 函数可用用来对 block 表 进行操作

#include <signal.h>

int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);

返回值：成功返回 0，失败返回 -1 并将错误码设置

参数1：对屏蔽信号集的操作

SIG_BLOCK 希望添加至当前进程 block 表中阻塞信号，从 set 信号集中获取，相当于 mask |= set
SIG_UNBLOCK 解除阻塞状态，也是从 set 信号集中获取，相当于 mask &= (~set)
SIG_SETMASK 设置当前进程的 block 表为 set 信号集中的 block 表，相当于 mask = set

参数2：就是一个信号集，主要从此信号集中获取屏蔽信号信息

参数3：也是一个信号集，保存进程中原来的 block 表（相当于给你操作后，反悔的机会）

这个函数就是参数 1 比较有讲究，主打的就是一个从 set 信号集中获取阻塞信号相关信息，然后对进程中的 block 表进行操作，并且有三种不同的操作方式

演示程序1：将 2 号信号阻塞，尝试通过键盘键入发出 2 信号

#include <iostream>
#include <unistd.h>
#include <signal.h>
using namespace std;

int main()
{
    //创建信号集
    sigset_t set, oset;

    //初始化信号集
    sigemptyset(&set);
    sigemptyset(&oset);

    //阻塞2号信号
    sigaddset(&set, 2);	//2 号信号被记录

    //设置当前进程的 block 表
    sigprocmask(SIG_BLOCK, &set, &oset);

    //死循环
    while(true)
    {
        cout << "我是一个进程，我正在运行" << endl;
        sleep(1);
    }

    return 0;
}

显然，当 2 号信号被阻塞后，是 无法被递达 的，进程也就无法终止了

演示程序2：在程序运行五秒后，解除阻塞状态

#include <iostream>
#include <unistd.h>
#include <signal.h>
using namespace std;

int main()
{
    // 创建信号集
    sigset_t set, oset;

    // 初始化信号集
    sigemptyset(&set);
    sigemptyset(&oset);

    // 阻塞2号信号
    sigaddset(&set, 2);	//2 号信号被记录

    // 设置当前进程的 屏蔽信号集
    sigprocmask(SIG_BLOCK, &set, &oset);

    // 死循环
    int n = 0;
    while (true)
    {
        if (n == 5)
        {
            // 采用 SIG_SETMASK 的方式，覆盖进程的 block 表
            sigprocmask(SIG_SETMASK, &oset, nullptr); // 不接收进程的 block 表
        }

        cout << "我是一个进程，我正在运行" << endl;
        n++;
        sleep(1);
    }

    return 0;
}

现象：在 2 号信号发出、程序运行五秒解除阻塞后，信号才被递达，进程被终止

如何证明信号已递达？

当 n == 5 时，解除阻塞状态，程序立马结束
并只打印了五条语句，证明在第六秒时，程序就被终止了
至于如何进一步证明，需要借助未决信号表

2.3、sigpending

这个函数很简单，获取当前进程中的未决信号集

#include <signal.h>

int sigpending(sigset_t *set);

返回值：成功返回 0，失败返回 -1 并将错误码设置

参数：待获取的未决信号集

如何根据未决信号集打印 pending 表

使用函数 sigismember 判断当前信号集中是否存在该信号，如果存在，输出 1，否则输出 0
如此重复，将 31 个信号全部判断打印输出即可

#include <iostream>
#include <cassert>
#include <unistd.h>
#include <signal.h>
using namespace std;

static void DisplayPending(const sigset_t pending)
{
    //打印 pending 表
    cout << "当前进程的 pending 表为: ";
    int i = 1;
    while(i < 32)
    {
        if(sigismember(&pending, i))
            cout << "1";
        else
            cout << "0";
        
        i++;
    }
    cout << endl;
}

int main()
{
    // 创建信号集
    sigset_t set, oset;

    // 初始化信号集
    sigemptyset(&set);
    sigemptyset(&oset);

    // 阻塞2号信号
    sigaddset(&set, 2);	//记录 2 号信号

    // 设置当前进程的 屏蔽信号集
    sigprocmask(SIG_BLOCK, &set, &oset);

    // 死循环
    int n = 0;
    while (true)
    {
        if (n == 5)
        {
            // 采用 SIG_SETMASK 的方式，覆盖进程的 block 表
            sigprocmask(SIG_SETMASK, &oset, nullptr);   // 不接收进程的 block 表
        }

        //获取进程的 未决信号集
        sigset_t pending;
        sigemptyset(&pending);

        int ret = sigpending(&pending);
        assert(ret == 0);
        (void)ret;    //欺骗编译器，避免 release 模式中出错

        DisplayPending(pending);

        n++;
        sleep(1);
    }

    return 0;
}

结果：当 2 号信号发出后，当前进程的 pending 表中的 2 号信号位被置为 1，表示该信号属于未决状态，并且在五秒之后，阻塞结束，信号递达，进程终止

疑问：当阻塞解除后，信号递达，应该看见 pending 表中对应位置的值由 1 变为 0，但为什么没有看到？

很简单，因为当前 2 号信号的执行动作为终止进程，进程都终止了，当然看不到
解决方法：给 2 号信号先注册一个自定义动作（别急着退出进程）

#include <iostream>
#include <cassert>
#include <unistd.h>
#include <signal.h>
using namespace std;

static void handler(int signo)
{
    cout << signo << " 号信号确实递达了" << endl;
    //最终不退出进程
}

static void DisplayPending(const sigset_t pending)
{
    // 打印 pending 表
    cout << "当前进程的 pending 表为: ";
    int i = 1;
    while (i < 32)
    {
        if (sigismember(&pending, i))
            cout << "1";
        else
            cout << "0";

        i++;
    }
    cout << endl;
}

int main()
{
    // 更改 2 号信号的执行动作
    signal(2, handler);

    // 创建信号集
    sigset_t set, oset;

    // 初始化信号集
    sigemptyset(&set);
    sigemptyset(&oset);

    // 阻塞2号信号
    sigaddset(&set, 2);	//记录 2 号信号

    // 设置当前进程的 屏蔽信号集
    sigprocmask(SIG_BLOCK, &set, &oset);

    // 死循环
    int n = 0;
    while (true)
    {
        if (n == 5)
        {
            // 采用 SIG_SETMASK 的方式，覆盖进程的 block 表
            sigprocmask(SIG_SETMASK, &oset, nullptr); // 不接收进程的 block 表
        }

        // 获取进程的 未决信号集
        sigset_t pending;
        sigemptyset(&pending);

        int ret = sigpending(&pending);
        assert(ret == 0);
        (void)ret; // 欺骗编译器，避免 release 模式中出错

        DisplayPending(pending);

        n++;
        sleep(1);
    }

    return 0;
}

显然，这就是我们想要的最终结果

先将信号阻塞，信号发出后，无法递达，始终属于未决状态，当阻塞解除后，信号可以递达，信号处理之后，未决表中不再保存信号相关信息，因为已经处理了

综上，信号在发出后，在处理前，都是保存在未决表中的

注意：

针对信号的增删改查都需要通过系统调用来完成，不能擅自使用位运算
sigprocmask、sigpending 这两个函数的参数都是信号集，前者是屏蔽信号集，后者是未决信号集
在对信号集进行增删改查前，一定要先初始化
信号在被解除阻塞状态后，很快就会递达了
关于信号何时递达、以及递达后的处理动作，在下一篇文章中揭晓
以上关于信号、信号集的操作都是在进程中进行的，不影响操作系统

3.信号的处理机制

3.1处理情况

普通情况

所谓的普通情况就是指 信号没有被阻塞，直接产生，记录未决信息后，再进行处理

在这种情况下，信号是不会被立即递达的，也就无法立即处理，需要等待合适的时机

特殊情况

当信号被阻塞后，信号产生时，记录未决信息，此时信号被阻塞了，也不会进行处理

当阻塞解除后，信号会被立即递达，此时信号会被立即处理

特殊情况很好理解，就好比往气球里吹气，当气球炸了，空气会被立即释放，因为空气是被气球阻塞的，当气球炸了之后（阻塞解除），空气立马往外跑，这不就是立即递达、立即处理吗？

3.2合适时机

信号的产生是异步的

也就是说，信号可能随时产生，当信号产生时，进程可能在处理更重要的事，此时贸然处理信号显然不够明智

比如进程正在执行一个重要的 IO，突然一个终止信号发出，IO 立即终止，对进程、磁盘都不好

因此信号在产生后，需要等进程将更重要的事忙完后（合适的时机），才进行处理

合适的时机：进程从内核态返回用户态时，会在操作系统的指导下，对信号进行检测及处理

至于处理动作，分为：默认动作、忽略、用户自定义

搞清楚 “合适” 的时机后，接下来需要学习用户态和内核态相关知识

4用户态与内核态

对于 用户态、内核态 的理解及引出的 进程地址空间 和 信号处理过程 相关知识是本文的重难点

4.1、概念

先来看看什么是 用户态和内核态

用户态：执行用户所写的代码时，就属于用户态

内核态：执行操作系统的代码时，就属于内核态

自己写的代码被执行很好理解，操作系统的代码是什么？

操作系统也是由大量代码构成的
在对进程进行调度、执行系统调用、异常、中断、陷阱等，都需要借助操作系统之手
此时执行的就是操作系统的代码

也就是说，用户态与内核态是两种不同的状态，必然存在相互转换的情况

用户态切换为内核态：

当进程时间片到了之后，进行进程切换动作
调用系统调用接口，比如 open、close、read、write 等
产生异常、中断、陷阱等
内核态切换为用户态：

进程切换完毕后，运行相应的进程
系统调用结束后
异常、中断、陷阱等处理完毕
信号的处理时机就是内核态切换为用户态，也就是当把更重要的事做完后，进程才会在操作系统的指导下，对信号进行检测、处理

下面来结合进程地址空间深入理解操作系统的代码及状态切换的相关内容（拓展知识）

4.2、重谈进程地址空间

首先简单回顾下进程地址空间的相关知识：

进程地址空间是虚拟的，依靠页表+MMU机制与真实的地址空间建立映射关系
每个进程都有自己的进程地址空间，不同进程地址空间中地址可能冲突，但实际上地址是独立的
进程地址空间可以让进程以统一的视角看待自己的代码和数据

不难发现，在 进程地址空间 中，存在 1 GB 的 内核空间，每个进程都有，而这 1 GB 的空间中存储的就是 操作系统 相关代码和数据，并且这块区域采用 内核级页表 与 真实地址空间 进行映射

为什么要区分 用户态 与 内核态 ？

内核空间中存储的可是操作系统的代码和数据，权限非常高，绝不允许随便一个进程对其造成影响
区域的合理划分也是为了更好的进行管理

所谓的执行操作系统的代码及系统调用，就是在使用这 1 GB 的内核空间

进程间具有独立性，比如存在用户空间中的代码和数据是不同的，难道多个进程需要存储多份操作系统的代码和数据吗？

当然不用，内核空间比较特殊，所有进程最终映射的都是同一块区域，也就是说，进程只是将操作系统代码和数据映射入自己的进程地址空间而已
而内核级页表不同于用户级页表，专注于对操作系统代码和数据进行映射，是很特殊的

当我们执行诸如 open 这类的系统调用时，会跑到内核空间中调用对应的函数

而跑到内核空间就是用户态切换为内核态了（用户空间切换至内核空间）

这个跑到是如何实现的呢？
在 CPU 中，存在一个 CR3 寄存器，这个寄存器的作用就是用来表征当前处于用户态还是内核态

当寄存器中的值为 3 时：表示正在执行用户的代码，也就是处于用户态
当寄存器中的值为 0 时：表示正在执行操作系统的代码，也就是处于内核态
通过一个寄存器，表征当前所处的状态，修改其中的值，就可以表示不同的状态，这是很聪明的做法

重谈进程地址空间后，得到以下结论

所有进程的用户空间 [0, 3] GB 是不一样的，并且每个进程都要有自己的用户级页表进行不同的映射
所有进程的内核空间 [3, 4] GB 是一样的，每个进程都可以看到同一张内核级页表，从而进行统一的映射，看到同一个操作系统
操作系统运行的本质其实就是在该进程的内核空间内运行的（最终映射的都是同一块区域）
系统调用的本质其实就是在调用库中对应的方法后，通过内核空间中的地址进行跳转调用

那么进程又是如何被调度的呢？

操作系统的本质
- 操作系统也是软件啊，并且是一个死循环式等待指令的软件
- 存在一个硬件：操作系统时钟硬件，每隔一段时间向操作系统发送时钟中断
进程被调度，就意味着它的时间片到了，操作系统会通过时钟中断，检测到是哪一个进程的时间片到了，然后通过系统调用函数 schedule() 保存进程的上下文数据，然后选择合适的进程去运行

4.3、信号的处理过程

当在 内核态 完成某种任务后，需要切回 用户态，此时就可以对信号进行检测并处理了

情况1：信号被阻塞，信号产生/未产生

信号都被阻塞了，也就不需要处理信号，此时不用管，直接切回 用户态 就行了

下面的情况都是基于 信号未被阻塞 且 信号已产生 的前提

情况2：当前信号的执行动作为默认

大多数信号的默认执行动作都是终止进程，此时只需要把对应的进程干掉，然后切回 用户态 就行了

情况3：当前信号的执行动作为忽略

当信号执行动作为忽略时，不做出任何动作，直接返回用户态

情况4：当前信号的执行动作为用户自定义

这种情况就比较麻烦了，用户自定义的动作位于 用户态 中，也就是说，需要先切回 用户态，把动作完成了，重新坠入 内核态，最后才能带着进程的上下文相关数据，返回 用户态

在内核态中，也可以直接执行自定义动作，为什么还要切回用户态执行自定义动作？

因为在内核态可以访问操作系统的代码和数据，自定义动作可能干出危害操作系统的事
在用户态中可以减少影响，并且可以做到溯源
为什么不在执行完自定义动作直接后返回进程？

因为自定义动作和待返回的进程属于不同的堆栈，是无法返回的
并且进程的上下文数据还在内核态中，所以需要先坠入内核态，才能正确返回用户态

注意：用户自定义的动作，需要先切换至 用户态 中执行，执行结束后，还需要坠入 内核态

通过一张图快速记录信号的处理过程

5.信号捕捉

接下来谈谈信号是如何被捕捉的

5.1、内核如何实现信号的捕捉？

如果信号的执行动作为 用户自定义动作，当信号递达时调用 用户自定义动作，这一动作称为 信号捕捉

用户自定义动作是位于用户空间中的

当内核态中任务完成，准备返回用户态时，检测到信号递达，并且此时为用户自定义动作，需要先切入用户态，完成用户自定义动作的执行；因为用户自定义动作和待返回的函数属于不同的堆栈空间，它们之间也不存在调用与被调用的关系，是两个独立的执行流，需要先坠入内核态（通过 sigreturn() 坠入），再返回用户态（通过 sys_sigreturn() 返回）

上述过程可以总结为下图

5.2sigaction

sigaction 也可以 用户自定义动作，比 signal 功能更丰富

#include <signal.h>

int sigaction(int signum, const struct sigaction *act,
                     struct sigaction *oldact);

struct sigaction 
{
	void     (*sa_handler)(int);	//自定义动作
	void     (*sa_sigaction)(int, siginfo_t *, void *);	//实时信号相关，不用管
	sigset_t   sa_mask;	//待屏蔽的信号集
	int        sa_flags;	//一些选项，一般设为 0
	void     (*sa_restorer)(void);	//实时信号相关，不用管
};

返回值：成功返回 0，失败返回 -1 并将错误码设置

参数1：待操作的信号

参数2：sigaction 结构体，具体成员如上所示

参数3：保存修改前进程的 sigaction 结构体信息

这个函数的主要看点是 sigaction 结构体

struct sigaction 
{
	void     (*sa_handler)(int);	//自定义动作
	void     (*sa_sigaction)(int, siginfo_t *, void *);	//实时信号相关，不用管
	sigset_t   sa_mask;	//待屏蔽的信号集
	int        sa_flags;	//一些选项，一般设为 0
	void     (*sa_restorer)(void);	//实时信号相关，不用管
};

其中部分字段不需要管，因为那些是与实时信号相关的，我们这里不讨论

重点可以看看 sa_mask 字段

sa_mask：当信号在执行用户自定义动作时，可以将部分信号进行屏蔽，直到用户自定义动作执行完成

也就是说，我们可以提前设置一批待阻塞的屏蔽信号集，当执行 signum 中的用户自定义动作时，这些屏蔽信号集中的信号将会被屏蔽（避免干扰用户自定义动作的执行），直到用户自定义动作执行完成

可以简单用一下 sigaction 函数

#include <iostream>
#include <cassert>
#include <cstring>
#include <signal.h>
#include <unistd.h>

using namespace std;

static void DisplayPending(const sigset_t pending)
{
    // 打印 pending 表
    cout << "当前进程的 pending 表为: ";
    int i = 1;
    while (i < 32)
    {
        if (sigismember(&pending, i))
            cout << "1";
        else
            cout << "0";

        i++;
    }
    cout << endl;
}

static void handler(int signo)
{
    cout << signo << " 号信号确实递达了" << endl;
    // 最终不退出进程

    int n = 10;
    while (n--)
    {
        // 获取进程的 未决信号集
        sigset_t pending;
        sigemptyset(&pending);

        int ret = sigpending(&pending);
        assert(ret == 0);
        (void)ret; // 欺骗编译器，避免 release 模式中出错

        DisplayPending(pending);
        sleep(1);
    }
}

int main()
{
    cout << "当前进程: " << getpid() << endl;
    
    //使用 sigaction 函数
    struct sigaction act, oldact;

    //初始化结构体
    memset(&act, 0, sizeof(act));
    memset(&oldact, 0, sizeof(oldact));

    //初始化 自定义动作
    act.sa_handler = handler;

    //初始化 屏蔽信号集
    sigaddset(&act.sa_mask, 3);
    sigaddset(&act.sa_mask, 4);
    sigaddset(&act.sa_mask, 5);

    //给 2号 信号注册自定义动作
    sigaction(2, &act, &oldact);

    // 死循环
    while (true);

    return 0;
}