Linux进程信号(2)--信号的保存
目录
1.阻塞信号
1.1 信号其他相关常见概念
1.实际执行信号的处理动作称为信号递达(Delivery）
2.信号从产生到递达之间的状态,称为信号未决(Pending)。
3.进程可以选择阻塞 (Block )某个信号。
1.2信号在内核中的表示
sigset_t
信号集操作函数
使用sigprocmask函数修改block表
使用sigpending函数查看pending表
1.阻塞信号
在解释信号的保存时，我们要先了解一下信号中的专有名词及其概念。
1.1 信号其他相关常见概念
1.实际执行信号的处理动作称为信号递达(Delivery）
信号递达，通俗来说就是处理信号。
处理信号的三种方式：
1.信号的忽略
2.信号的默认
3.信号的自定义捕捉
信号的默认
这里我们先编写一个程序：
#include
#include
#include
int main()
{
while(true)
{
std::cout<<"getpid():"< 运行起来，然后再使用kill -信号编号 进程pid。给进程发送信号。
这里就是信号9的默认。
信号的自定义
这里我们要使用函数：
sighandler_t signal(int sugnum,sighandler_t handler)
这里signum是你想自定义信号的编号，handler一个函数指针，指向的是返回值为void，参数为一个int的函数。（这里也可以用一个宏SIG_DFL恢复信号的默认处理）
作用：收到信号，不按照默认方式，自定义处理信号。
#include
#include
#include
void handler(int signal)//自定义处理信号2的内容
{
std::cout<<"handler:"< 
使用宏SIG_DFL恢复默认处理：
#include
#include
#include
void handler(int signal)//自定义处理信号2的内容
{
std::cout<<"handler:"< 
信号的忽略
这里还是使用函数signal,但是要使用宏SIG_IGN才能实现函数忽略。
代码：
#include
#include
#include
void handler(int signal)//自定义处理信号2的内容
{
std::cout<<"handler:"< 
这里我们可以看到当我们向进程发送信号2时，它并没有退出进程，所以它忽略了信号2.
这里可能大家会有这样的疑问？
signal函数的第二个参数是一个函数指针，为什么可以使用宏SIG_DFL与SIG_ING呢？
这里我们可以直接看这两个宏的定义：
这里我们可以看出，将0强转成了函数指针类型，1也强转成了函数指针类型。
如何看待信号的忽略？
这里忽略，就是处理信号。
2.信号从产生到递达之间的状态,称为信号未决(Pending)。
这里我们知道，如果当进程收到信号时，正在执行更为重要的事务，进程并不会立马处理信号，而是先将信号保存下来，等待合适的时机再处理。所以在信号产生，到信号处理（信号递达）这段时间里我们叫做信号未决。
这里我们知道，保存信号是使用位图来保存的，信号未决具体点可以理解为：在信号位图中，就叫做信号未决。
3.进程可以选择阻塞 (Block )某个信号。
举例理解：
在上课前老师留下了放假作业（接受信号，保存），但是因为上课要听老师讲课，我们不能在课堂上写作业（被阻塞），我们只能在放学后才能写作业（接触阻塞）。
注：
1.信号未决不一定阻塞，但收到信号并阻塞，一定未决。
2.没有收到信号，可以设置信号的递达动作。
3.没有收到信号，可以设置信号阻塞，也可以解除阻塞。
4.阻塞与忽略是不同的，只要信号被阻塞就不会递达，而忽略是在递达之后可选的一种处理动作。
1.2信号在内核中的表示
上面，我们介绍了信号的递达，未决，阻塞。在OS里是这样实现的。
首先有block，pending，handler三张表，其中：
pending表：是信号未决表，表的下标代表着是几号信号，表的内容代表着是否收到信号。（使用位图的方式记录）
handler表：对应信号的处理方法，里面可以存放函数指针，或者是SIG_DFL/SIG_ING这样的宏。数组的下标代表着信号编号-1。
这里在进程启动时，就形成了这两张表。因此在进程收到信号前，就认识信号（如何处理信号）
block表：信号阻塞表，pending表一样，使用了位图。比特位的位置：表示信号编号。比特位的内容表示，是否对特定的信号进行屏蔽(阻塞)。
对于一个信号的识别，使用这三张表，要横着看
比如以1号信号为列：
当我们收到1号信号时，我们先将pending表中对应的比特位置为1，然后再看block表中对应的比特位的内容，为0，表示不阻塞，在合适的时候，会在handler表中找到对应的方法处理信号。若为1，则表示信号阻塞，不会对信号进行任何处理，等到比特位的内容变为0，会在合适的时候，在handler表中找到对应的方法处理信号。
因此在收到信号时，能不能被处理，首先取决于对因block表中内容。
上面我们知道对于信号的处理取决于PCB中的这三张表，因此如果我们要控制进程对信号的处理，那么就需要改变这三张表的内容，但是对于我们用户来说，我们并不清楚这三张是如何存储。因此操作系统为我们提供了一系列的系统调用函数，来帮助我们。
sigset_t
信号集操作函数
#include
//将位图里的比特位全部清零
int sigemptyset(sigset_t *set);
//对指定的位图全部置1
int sigfillset(sigset_t *set);
//将指定信号集中的指定比特位置1
int sigaddset (sigset_t *set, int signo);
//将指定信号集中的指定比特位置0
int sigdelset(sigset_t *set, int signo);
//判定一个信号是否在信号集中
int sigismember（const sigset_t *set, int signo); 使用sigprocmask函数修改block表
调用函数sigprocmask可以读取或更改进程的信号屏蔽字(阻塞信号集）
#include
int sigprocmask(int how, const sigset_t *set, sigset_t *oset);
set为想要修改的信号，
oset记录调用前的block，用于恢复原来的block
返回值:若成功则为0,若出错则为-1 如果 oset 是非空指针 , 则读取进程的当前信号屏蔽字通过 oset 参数传出。如果 set 是非空指针 , 则 更改进程的信号屏蔽字, 参数 how 指示如何更改。如果 oset 和 set 都是非空指针 , 则先将原来的信号 屏蔽字备份到 oset 里 , 然后根据set 和 how 参数更改信号屏蔽字。假设当前的信号屏蔽字为 mask, 下表说明了 how 参数的可选值
代码演示：屏蔽2号信号。
#include
#include
#include
void handler(int signal)//自定义处理信号2的内容
{
std::cout<<"handler:"< 
这里可能有人会这样问，既然我们可以控制屏蔽信号，那么如果我们把所有信号都屏蔽了，是不是一旦这样的死循环进程运行起来，是不是就不会被杀掉了？
这里我们直接上代码演示：
#include
#include
#include
void handler(int signal)
{
std::cout<<"handler:"< 
这里我们可以发现当我们对进程发送除9之外的信号，进程并不会停止（信号被屏蔽），而当收到9信号时，进程就直接执行信号9对应的默认动作。(19号信号也没有被屏蔽)
9号信号我们成为管理员信号，它并不会被屏蔽。
使用sigpending函数查看pending表
#include
int sigpending(sigset_t *set)
读取当前进程的未决信号集,通过set参数传出。调用成功则返回0,出错则返回-1。 下面用刚学的几个函数做个实验。程
序如下 这里我们直接上代码：
解释程序目的，不断打印pendling表中比特位的内容。在最开始的前10秒，阻塞信号2。然后将信号2从block表中删除，我们要在10秒前向进程发送2号信号。
#include
#include
#include
void handler(int signal)
{
std::cout<<"handler:"<=1;signo--)
{
if(sigismember(&pending,signo))
{
std::cout<<'1';
}
else
{
std::cout<<'0';
}
}
std::cout< 
这里我们可以看到一旦信号2，不阻塞，就立即递达了。并且pending表中对应的比特位置0.
这里可能有人会问pending表置0这个操作是在处理信号前，还是后执行的？
这里我们可以直接用代码验证：
#include
#include
#include
void PrintPending(sigset_t& pending);
void handler(int signal)
{
std::cout<<"#####################"<=1;signo--)
{
if(sigismember(&pending,signo))
{
std::cout<<'1';
}
else
{
std::cout<<'0';
}
}
std::cout< 
这里我们采用的是，自定义信号2，在处理时，将pending表的内容打印出来，如果全部位0，则在修改pending实在递达前实行的，否则实在递达之后修改的。