（28）Linux 信号保存 &&信号处理 && 不可重入函数
首先介绍几个新的概念：
- 信号递达(Delivery)：实际执行信号的处理动作。
- 信号未决(Pending)：信号从产生到递达之间的状态。
- 信号阻塞(Block)：被阻塞的信号产生时将保持在未决状态，直达解除对该信号的阻塞，才执行递达动作。
注意： 阻塞和忽略是不同的，只要信号被阻塞就不会被递达，但是忽略是在递达之后进行的一种处理动作。
一、信号保存
信号在内核中的表示示意图
- 每个信号都有两个标志位分别表示阻塞(block)和未决(pending),还有一个函数指针表示处理动作。信号 产生时,内核在进程控制块中设置该信号的未决标志,直到信号递达才清除该标志。在上图的例子 中,SIGHUP信号未阻塞也未产生过,当它递达时执行默认处理动作。
- SIGINT信号产生过,但正在被阻塞,所以暂时不能递达。虽然它的处理动作是忽略,但在没有解除阻塞之前不能忽略这个信号,因为进程仍有机会改变处理动作之后再解除阻塞。
- SIGQUIT信号未产生过,一旦产生SIGQUIT信号将被阻塞,它的处理动作是用户自定义函数sighandler。如果在进程解除对某信号的阻塞之前这种信号产生过多次,将如何处理?POSIX.1允许系统递送该信号一次或多次。Linux是这样实现的:常规信号在递达之前产生多次只计一次,而实时信号在递达之前产生多次可 以依次放在一个队列里。本章不讨论实时信号。
当我们使用signal注册一个自定义处理方式时，操作系统会将我们定义的函数指针放在handler表中，在信号递达后调用。如果是默认处理方式，会调用handler默认的初始函数指针所对应的函数。
信号产生后，操作系统就会修改pending位图，使信号处于未决状态。
操作系统会按照一定的顺序来检查block表和pending表，然后去调用相应信号编号的处理方式来完成信号递达。大概逻辑(伪代码)：
if(1<<(signo - 1) & pcb->block)
{
//signo信号被阻塞，不会被递达
}
else
{
if(1<<(signo - 1) & pcb->pending)
{
//信号递达，处理该信号
handler[signo - 1];
}
}
操作系统在对信号进行检测的时候，先检测的是信号的block位图，如果对应信号的比特位被置一，说明该信号被阻塞，就不再去检测pending位图。如果没有被阻塞，才会去检测pending位图，如果相应的位被置一，再去调用handler表中的处理函数。
结论： 如果一个信号没有产生，但是并不妨碍它被阻塞。
被阻塞的信号，在产生之后就会一直处于未决状态，不会被递达，只有当阻塞被解除后才会被递达。
默认情况下，所有信号都是不被阻塞的，所有信号都没有产生，也就是block位图和pending位图都是0。
信号集操作函数
pending图，block图以及handler表是存放在内核数据结构中的，所以只能由操作系统来修改，我们用户如果要修改也能通过操作系统来实现，所以操作系统同样给我们提供了系统调用。
- handler表中的函数指针可以通过系统调用signal来设置。
对于block位图和pending位图的修改，操作系统提供了一族系统调用，称为信号集操作函数。
- sigset_t set：信号集变量。
- int signum：信号编号。
- 返回值：成功返回0，失败返回-1。
信号集：
用户在设置pending位图和block位图的时候，并不能直接让系统调用将内核中对于的比特位置一或清0，而是需要预先在一个变量中表达出我们的意愿，然后将这个变量通过系统调用给到操作系统，再由操作系统去修改内核数据结构。
- 操作系统给我们提供了一个sigset_t的变量类型，用户只需要对这个变量进行预设置，然后再交给操作系统。
系统提供的信号集操作函数操作的也是也是这个域先处理的变量，之所以也用系统调用来处理这个变量，是因为这个变量不单单是一个32位的整形变量，它的结构和内核是对应的，所以操作也要按照相应的规则。
- 从使用者的角度不必关心具体是如何操作的，只需要使用信号集操作函数来操作sigset_t变量即可。
- sigset_t变量用其他方式是无法操作的，比如用printf去打印，这是没有意义的。
代码演示：
int main()
{
sigset_t block,pending;
//清空位图
sigemptyset(&block);
sigemptyset(&pending);//---初始化位图
//所有位置，置一
sigfillset(&block);
sigfillset(&pending);//---设置所有信号
//指定位置，置一
sigaddset(&block,2);
sigaddset(&pending,2);//---设置指定信号
//指定位置清空
sigdelset(&block,2);
sigdelset(&pending,2);//---判断指定信号
//判断指定位置是否置一
bool ret1=sigismember(&block,2);
bool ret2=sigismember(&pending,2);
return 0;
}- sigemptyset：使所有信号对应的bit清零，表示该信号集不包含任何有效信号。
- sigfillset：使所有信号对应的bit置位，表示该信号集的有效信号包括系统支持的所有信号。
- sigaddset：使指定信号所对应的bit置位，表示该信号集中对应信号有效。
- sigdetset：使指定信号所对应的bit清零，表示该信号集中对应信号无效。
- sigismember：判断指定信号所对应的bit是否有效，返回类型是bool类型。
在使用sigset_t类型的变量之前，一定要调用sigemptyset进行初始化，使信号集处于确定状态。
此时我们已经对sigset_t变量预处理好了，下一步就是把这个变量交给操作系统了，操作系统同样提供了对应的系统调用。
sigprocmask():
该系统调用是专门用来修改内核数据结构中的block位图的。
#include
int sigprocmask(int how, const sigset_t *set, sigset_t *oset);
set：这是一个输出型参数，用来返回从内核中获取的pending位图情况。
返回值:若成功则为0,若出错则为-1 
#include
#include
#include
#include
#include
using namespace std;
void handler(int signo)
{
cout<<"信号已送达，编号是："<=1;--signo){
//该位信号有效打印1，否则打印0
if(sigismember(&pending,signo))//判断位图比特位是否为1
{
cout<<"1";
}
else{
cout<<"0";
}
}
cout< sigarr={2,3};//存放要被屏蔽的信号编号
int main()
{
sigset_t block,pending,oblock;
//清空位图
sigemptyset(&block);
sigemptyset(&pending);//---初始化位图
//添加想要屏蔽的信号
for(auto& signo:sigarr){
sigaddset(&block,signo);//添加屏蔽信号
//自定义处理指定信号
signal(signo,handler);
}
//开始屏蔽，设置进内核
sigprocmask(SIG_SETMASK,&block,&oblock);//使置进内核的block位图中
//打印pending位图
while(1){
//初始化
sigemptyset(&pending);
//获取内核中的pending位图
sigpending(&pending);
//打印
Show_pending(pending);
sleep(1);
}
return 0;
} 运行结果：
- 在接收到2号信号以后，pending位图的第二个比特位置一，表明该信号处于未决状态。
- 在接收到3号信号以后，pending位图的第三个比特位也置一，表明该信号也处于未决状态。
- 无论哪个信号产生，都没有递达，因为没有执行自定义处理函数。
所以说，被阻塞的信号，即使产生也是处于未决状态，不会被递达。
int cnt=0;
while(1){
//初始化
sigemptyset(&pending);
//获取内核中的pending位图
sigpending(&pending);
//打印
Show_pending(pending);
sleep(1);
if(++cnt==10){
cout<<"解除屏蔽"<运行结果：
- 原本2号和3号信号被阻塞，即使产生也处于未决状态，没有被递达。
- 当解除阻塞以后，被阻塞的信号便递达了，自定义处理方式中打印出了信号编号。
- 信号递达后，对应pending位图中的比特位被自动清零。
二、信号处理
现在我们知道，进程在接收到信号后并不是立刻处理的，而是在适当的时候，那这个适当的时候到底是什么时候呢？
- 从内核态返回用户态的时候信号递达。
信号只是处理的话非常简单，就是在执行默认的处理方式或者自定义方式，再或者是忽略，最重要的是信号处理的时机，也就是信号的捕获。
1、捕捉信号
信号的捕捉：
- 用户为了访问内核或者硬件资源，必须通过系统调用才能完成访问。
- 用户态：正在执行用户层的代码，此时CPU的状态是用户态。
- 内核态：正在通过系统调用访问内核或者硬件资源时，此时CPU的状态是内核态。
虽然系统调用是在我们的代码中写的，也就是用户在使用，但是具体的执行者是内核，也就是操作系统。
现在是知道了什么是用户态，什么是内核态，但是操作系统是怎么知道当前进程的身份状态的呢？
CPU中的寄存器虽然只有一套，但是有很多，有可见寄存器，如eax，ebx等等，还有很多的不可见寄存器，凡是和当前进程强相关的，都属于当前进程的上下文数据。
如上图中：
- 有专门用来存放当前进程PCB指针的寄存器。
- 也有专门存放当前进程页表指针的寄存器。
- CR3寄存器：专门用来表征当前进程的运行级别的。
- 0：表示内核态，此时访问的是内核资源或者硬件。
- 3：表示用户态，此时执行的是用户层的代码。
操作系统是一个进行软硬件资源管理的软件，它很容易就可以获取到CPU中CR3寄存器中是0还是3，从而知道当前是用户态还是内核态。
执行系统调用时，执行者是操作系统，而不是用户。那么又存在一个问题，一个进程是怎么跑到操作系统中执行代码的呢？
对进程地址空间进行一个补充介绍：
我们之前一直所说的页表都是用户级页表，每个进程都有一个。
进程地址空间的大小一共有4GB，我们之前谈论的只有0~3GB，这3GB的空间属于用户空间，用来存放用户的代码，数据等。为了保证进程的独立性，每个进程都有一个进程地址空间，都有一个用户级页表。
还有一共内核级页表，所有进程共用一份。
进程地址空间中的3~4GB空间，是不允许用户访问的，因为这1GB空间中的数据等，通过内核级页表和内存中的操作系统相映射，属于内核级别的。因为内存中只存在一份内核，所以所有进程的虚拟地址空间的这1GB空间都通过同一份内核级页表和内存中的内核相映射。
- 每一个进程地址空间中的3~4GB的内容都是一样的，因为它们都通过同一个内核级页表和内存中的内核相映射。
还记得动态链接吗？通过代码段的位置无关码跳转到共享区从内存中映射过来的动态库来执行相应的方法。系统调用和它的原理一样：
- 当执行到代码段中的系统调用时，会在跳转到当前进程虚拟地址空间中的内核空间中。
- 系统调用的具体实现都放在这1GB的内核空间中。
- 然后根据内核级页表和内存中内核的映射关系实现内核的访问。
此时又有一个问题，为什么我们的代码中不能访问这3~4GB的空间，而系统调用就跳转到这1GB的内核空间中进行访问了呢？我们都是用户的代码啊？
- 因为从代码段跳转到内核空间中后，CPU中的CR3寄存器从3变成了0。
- 意味着进程运行级别从用户态变成了内核态，也就是执行者从用户变成了操作系统，所以可以对这1GB的内核空间进行访问。
- 系统调用接口的起始位置，会将CR3寄存器中的数据从3变成0，完成从用户态向内核态的转变。
所以说，系统调用前一部分是由用户在执行，其余部分由操作系执行。
此时再来理解信号处理的时机—从内核态返回到用户态，这句话的含义：
- 必然曾经进入到了内核态，而进入内核态的方式很多，比如进程切换，只有操作系统才有权力将进程从CPU上剥离下来换上另一个进程。还有系统调用，等等方式。
以我们最熟悉的系统调用为例：
以黑色长线为界，上面是用户态，下面是内核态。
- 当执行到用户代码段中的系统调用时，会跳转掉虚拟地址空间中的内核空间去执行具体的方法，此时从用户态变成了内核态。
- 当系统调用被操作系统执行完毕以后，在返回之前(来一趟挺不容易的)，操作系统会检测task_struct中block位图，pending位图，然后再根据handler中的处理方式去处理相应的信号。
- 如是自定义处理方式，操作系统会拿着handler表中的函数地址，通过特定的系统调用去执行用户自定义的处理方式，此时从内核态变成了用户态。
- 在执行完自定义处理方式以后，再次回到内核中取系统调用得到的数据，此时再次从用户态变成了内核态。
- 拿上要取的数据以后，通过特定的系统调用返回到用户代码中系统调用的位置，再次从内核态变成了用户态。
上面过程的伪代码形式：
涉及到的系统调用无需详细了解，只需要知道是通过系统调用实现的即可。
两个独立的流程：
此时就存在了两个流程，一个是main函数所在的执行流程，一个是自定义处理方式的执行流程：
- 在执行完系统调用后不是恢复main函数的上下文进行执行，而是执行用户自定义的处理方式。
- 自定义处理方式函数和main函数使用不同的堆栈空间，并且不存在调用和被调用的关系，是两个独立的控制流程。
- 上面整个过程可以看成一个无穷大符号加一条线，线的上边是用户态，下边是内核态。
- 每经过一次黑线就会发生一次身份状态的改变，一共改变了四次。
上面这种自定义处理方式是最复杂的情况，如果是SIG_DFL(默认处理方式)和SIG_IGN(忽略方式)，以内核态身份就可以处理，然后就可以直接返回到用户代码中系统调用的位置，少了两次身份的转变。
因为默认方式和忽略方式是被写入到操作系统中的，被操作系统所信任的方式。
- 默认处理方式：所有信号的默认处理方式都是结束进程，只是不同信号表示不同的异常。
- 忽略处理方式：忽略和阻塞不一样，忽略也是一种处理方式，它仅仅是将task_struct中的pending位图中对应信号的比特位清空，然后就直接返回到用户态了。
2. sigaction
int signum：信号编号。
act：这是一个结构体变量，结构体中包括多个属性，sa_handler赋值自定义处理方式，暂时将sa_flags都设为0，其他暂时不用管。
oldact：是一个输出型的结构体变量，将原本的捕捉方式放入这个结构体变量中。
返回值：成功返回0，失败返回-1。
代码演示：
#include
#include
#include
#include
#include
using namespace std;
void Count(int cnt)
{
while(cnt){
printf("cnt:%2d\r",cnt);
fflush(stdout);
cnt--;
sleep(1);
}
}
void handler(int signo)
{
cout<<"信号已送达，编号是："< - 将自定义处理方式赋值给结构体变量act中的sa_handler。
- 使用系统调用sigaction注册自定义处理方式。
- 在自定义处理函数中，打印捕捉到的信号编号，然后进行10s种延时。
运行结果：
在进程开始运行后，我们在10s内发送了很多次2号信号，但是最终只捕获了两次。
- 当递达第一个2号信号的时候，同类型的信号无法被递达。
- 因当前信号在被捕捉的时候，系统会自动将当前信号加入到进程的信号屏蔽字，也就是将block对应的比特位置位，然后将pending表对应比特位清空，再去进行递达。
- 但是第二个2号信号在第一个信号被捕捉的时候会将对应pending位图的比特位置位。
- 所以当第一个2号信号处理完毕以后，解除对2号信号的屏蔽后，第二个2号信号就会被递达。
- 除了这两个2号信号，其余的2号信号都被舍弃了。
注意： 进程处理信号的原则是串行的处理同类型的信号，不允许递归，所以同类型的多个信号同时产生，最多可以处理两个。
- 如果想要在捕获2号信号以后，将3号信号也屏蔽了呢？
- 此时就需要设置结构体变量act中的sa_mask成员。
运行结果：
在10s内，多次发送2号和3号信号。
- 当第一次2号信号被捕获后，第二个2号信号虽然被阻塞了，但是它还是让pending位图置位了。
- 当第一次2号信号被递达完成后，就会递达第二个2号信号。
- 当第二次2号信号被递达完成后，2号信号的pending位图的比特位是0，所以才递达3号信号。
- 虽然在捕获2号信号的同时会阻塞3号信号，但是3号的pending位图的比特位仍然被置位了。
在第一个2号信号被捕获的时候，同时阻塞了第二个2号信号和3号信号，此时pending位图的第二个和第三个比特位都是1，但是当第一个2号信号递达完成后，先处理的是第二个2号信号而不是3号信号。
一般一个信号被解除屏蔽的时候，会自动递达这个信号，如果该信号pending位图的比特位是1的话就会递达，是0的话就不做任何处理。
三、不可重入函数
如上图所示链表，在插入节点的时候捕获到了信号，并且该信号的自定义处理方式中也调用了插入节点的函数。
- main函数调用insert函数向一个链表head中插入节点node1,插入操作分为两步,刚做完第一步的 时候,因为硬件中断使进程切换到内核,再次回用户态之前检查到有信号待处理,于是切换 到sighandler函 数,sighandler也调用insert函数向同一个链表head中插入节点node2,插入操作的 两步都做完之后从 sighandler返回内核态,再次回到用户态就从main函数调用的insert函数中继续 往下执行,先前做第一步之后被打断,现在继续做完第二步。结果是,main函数和sighandler先后 向链表中插入两个节点,而最后只有一个节点真正插入链表中了。
- 像上例这样,insert函数被不同的控制流程调用,有可能在第一次调用还没返回时就再次进入该函数,这称 为重入,insert函数访问一个全局链表,有可能因为重入而造成错乱,像这样的函数称为 不可重入函数,反之, 如果一个函数只访问自己的局部变量或参数,则称为可重入(Reentrant) 函数。想一下,为什么两个不同的 控制流程调用同一个函数,访问它的同一个局部变量或参数就不会造成错乱?
- 调用了malloc或free,因为malloc也是用全局链表来管理堆的。
- 调用了标准I/O库函数。标准I/O库的很多实现都以不可重入的方式使用全局数据结构。
volatile 关键字
定义全局变量quit，当quit是0的时候，一直进行while循环，当quit变成1的时候，结束循环，进程正常退出。
信号2注册自定义处理方式，在函数中将全局变量改成1，让main函数控制的流程正常结束。
在接收到2号信号后，quit从0变成1，所以main流程也正常结束了，不再循环。
我们的编译器会进行很多的优化，比如debug版本和relase版本中的assert就会被优化。在使用g++编译器的时候，可以指定g++的优化级别。
g++ -o $@ $^ -03 -std=c++11指定使用级别为3的编译器优化选项。
仍然是上面代码，运行起来后，发送2号信号，quit是从0变成了1，但是进程并没有结束，还是在运行，再次发送2号信号，quit从1变成1，进程还在继续。
此时可以肯定quit被改成了1，但是while(!quit)还是在循环，没有停下来。
上诉现象的原因是什么？肯定是和优化有关，因为我们加了-O3选项。
- quit在物理内存中一定有一块空间，最开始是0。
- 当CPU指向while(!quit)；指令的时候，会通过虚拟地址和页表的映射将物理内存中的quit数据取到CPU的寄存器中。
- 当quit被修改后，物理空间中的数据就会从0变成1。
在没有优化前，CPU每次都是从物理内存中拿到quit的数据，再去指向while循环，所以当quit从0变成1后，CPU中寄存器的数据也会及时从0变成1，所以while循环会停下来。
但是采用优化方案后：
- 在main控制的执行流中，quit没有进行修改，也没有写入，只是被读取，所以在第一次将从物理空间读取到寄存器中便不再读取了，每次执行while时候都是使用的寄存器中的quit值，所以始终都是0。
- 在handler执行流中，对quit进行了修改，所以物理内存中的quit从0变成了1。
导致上面现象的原因就是CPU执行while时的quit和物理内存中的quit不是一个值。
- 为了让CPU的寄存器每次都从物理内存中取数据，使用volatile关键字来修饰这个quit变量。
可以看到，此时在handler的执行流中修改了quit值，并且CPU中该值也得到了及时更新，所以程序可以正常结束。
总结
至此，加上上一篇文章，信号的整个生命周期都介绍完了，重点在于新的产生，信号保存，以及信号捕捉上面，其它衍生的知识了解即可。