【Linux】进程信号捕捉

前言

在【Linux】进程信号及信号产生中，我们提到，进程接收到信号，并不是立刻处理，而是在合适的时候才执行相应的动作，那合适的时候是什么时候呢，进程捕捉信号的过程究竟是怎么样的呢？本篇博客就来一一讲解

一. 合适的时候

首先，进程信号一般都不是立刻处理的，但也可以立刻被处理：
当一个信号之前处于阻塞（block）状态，那么当阻塞状态解除后，该信号会被立刻递达，处理
因为信号的产生对于进程来说是异步的，可能信号产生时，当前进程正在做一些优先级高的任务，那么此时就需要将当前任务做完，才处理信号。所以信号不是都立刻处理的

那么什么时候才是合适的时候呢？
OS规定，当进程从 内核态 切换到 用户态时，进程会在OS的指导下，进行信号的检测和处理

二. 内核态 / 用户态

用户态：执行我们自己写的代码的时候，进程所处的就是用户态。
内核态：执行OS的代码的时候，进程所处的就是内核态。

用户态我们可以理解，但是内核态的OS的代码是什么意思呢？

1. 进程时间片到了，需要切换进程，就要执行进程切换逻辑
2. 系统调用：sleep，C/C++的printf和cout，内部都封装了和键盘，显示器交互的系统调用

这些都是OS的代码。

这里我们还需要引入一些虚拟地址空间

1. 其中，[0，3]GB是用户空间，其中的代码和数据会通过用户级内标映射到物理内存
2. [3,4]GB是内核空间，其中的代码和数据会通过内核级页表映射到物理内存。
3. 在电脑开机，启动Linux时，其实就是将OS的代码和数据加载到物理内存中
4. 每个进程的用户空间并不相同，但是内核空间是一样的，每个进程都有自己的用户级页表，但是每个进程看到的都是同一个内核级页表，这样所以进程都可以通过统一的窗口，看到同一个OS

所以，用户态，其实就是访问用户空间的代码和数据；而内核态，则是访问内核空间的代码和数据
系统调用的本质，就是从用户空间，进行函数跳转到内核空间，执行相应方法，最后再返回用户空间
但是这就引发一个问题：那这样我们会不会就可以直接访问OS的代码？
答案肯定是不行。
为了防止我们访问，就划分出了用户态和内核态
在CPU中，有一个CR3寄存器。
内部如果标记为3：表征正在运行的进程执行级别是用户态
内部如果标记为0：表征正在运行的进程执行级别是内核态
而在所有的OS提供的系统调用，内部在正式执行调用逻辑前，都会去修改执行级别

如果用户去访问内核空间，CPU会先检查到要访问[3，4]空间，进而检查当前进程的执行级别，发现是3，用户态时，就会将非法访问寄存器标记为1，进而产生硬件中断，OS检测到硬件中断，就会给当前进程发送终止信号

而OS无法仅靠内核空间管理软硬件，他自己也有进程：1号进程就是OS的进程

三. 进程调度

有了虚拟地址空间的了解，我们还需要了解进程调度，理解时间片

时间片
时间片就是一个进程获得CPU资源的时间

首先，OS是一个软件，本质是一个死循环，会一直检测有没有收到中断
计算机有一个硬件，叫晶体震荡器，即使电脑关机，这个硬件依然做着记录时间的工作。
该硬件会在很短的时间内，给OS发送时钟中断，OS就要执行对应的中断方法。
这个中断方法就包括检测当前进程的时间片

进程的pcb会记录进程被调度的时间，OS可以凭借时钟，判断当前进程的时间片是否结束。
如果时间片到了，会保存上下文（执行到哪），代码，数据，然后切换到另一个进程
这些操作其实都是一个系统调用——schedule()

而因为用户空间和内核空间都在一起，其实就相当于当前进程自己切换了进程。
检测时间片，切换进程等其实都是在当前进程中进行的，OS会在当前进程的上下文运行

四. 状态切换

有了以上的知识储备，我们要分析一下一个进程运行的状态切换。

我们用这个图辅助理解

1. 首先，我们是运行用户代码，而一旦使用系统调用函数，或者时间片到达（本质也是使用系统调用函数），就会切换到内核态
2. 切换到内核态完成系统调用后，在切换回用户态之前，会进行信号检测的系统调用。检测当前进程的pengding表，block表。一旦pengding表的一个比特位为1，block表相应比特位为0，代表收到该信号，则进行handler表内相应方法的执行：

执行方法有三种：1.SIG_DFL（默认动作，终止进程） 2. SIG_IGN（忽略）3. 自定义动作。
其中SIG_DFL和SIG_IGN都是系统调用，不用切换，但是自定义动作就需要切换到用户态执行用户提供的方法

3. 如果是自定义信号捕捉动作，则需要切换到用户态，执行相应方法，再切换到内核态。因为最开始从用户态切换到内核态时，上下文是保存在内核中的，用户并不知道，所以无法在执行自定义动作后直接继续执行原先用户的代码，还需要再切换到内核态。切换的函数是sigreturn()
4. 自定义动作执行完成后，切换回内核态，再继续检查是否还有别的信号，最后再调用sys_sigreturn切换回用户态

所以，如果对于一个信号，我们进行了捕捉，使其执行自定义动作
那么，在时间片到达或者用户调用系统调用时，就会发生四次切换
第一次，从用户切换到内核执行系统调用
第二次，从内核切换到用户态之前，进行信号检测，发现信号，执行自定义动作，切换到用户态
第三次，从用户态执行完自定义动作，切换到内核态
第四次，信号检测完毕，从内核态切换到用户态原先的代码位置

这就是信号捕捉的状态切换

五. 信号捕捉

在之前的博客，我们讲过signal()函数，可以对特定信号进行捕捉

signum：捕捉signum号信号
handler：自定义动作

还有一个信号捕捉的系统调用是sigaction()

signum：捕捉signum信号
sigaction结构体：

sa_handler：自定义动作
sa_sigaction：和实时信号相关，不作讨论
sa_mask：执行signum的handler方法时，可再屏蔽其他信号
sa_flags：默认传0
sa_restorer：和实时信号相关，不作讨论

接下来，我们进行一个实验，使用一下sigaction()函数
当一个信号要执行handler表的动作前，OS会将pending表由1置为0，表示该信号被处理了
首先，当某个信号的处理函数被调用时，内核自动将当前信号加入进程的信号屏蔽字，当信号处理函数返回时自动恢复原来的信号屏蔽字，这样就保证了在处理某个信号时，如果这种信号再次产生，那么，它会被阻塞到当前处理结束为止。
首先我们先验证一下

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

using namespace std;

//打印pending表
void printPending(const sigset_t &pending)
{
    for(int signo=1;signo<=31;signo++)
    {
        //查询pending表内是否有signo号信号
        if(sigismember(&pending,signo))
        {
            cout<<1;
        }
        else
        {
            cout<<0;
        }
    }
    cout<<endl;
}

//自定义动作
void handler(int signo)
{
    cout<<"对特定信号:"<<signo<<"执行捕捉动作"<<endl;
    int cnt=5;
    while(cnt--)
    {
        //获取pending表
        sigset_t pending;
        sigemptyset(&pending);
        sigpending(&pending);
        //打印pending表
        printPending(pending);
        sleep(1);
    }
}

int main()
{
    struct sigaction act,oldact;
    memset(&act,0,sizeof(act));
    memset(&oldact,0,sizeof(oldact));
    act.sa_flags=0;
    //自定义动作
    act.sa_handler=handler;
    sigemptyset(&act.sa_mask);
    //对2号信号进行捕捉
    sigaction(2,&act,&oldact);

    while(true)
    {
        cout<<getpid()<<"进程执行中..."<<endl;
        sleep(1);
    }

    return 0;
}

运行结果如下

我们第一次ctrl+c，2号信号被捕捉，执行自定义动作，打印pending表
可以看到此时pending表为全0，代表执行自定义动作前，pending表被处理信号就已经置为0了
当我们再执行自定义动作时，再ctrl+c，发现pending表接收到2号信号，但是没有处理，因为此时2号信号处于堵塞状态
而当第一次自定义动作执行完后，切换回内核态，又在pending表检测到2号信号，所以再执行自定义动作。

而sa_mask可以在执行自定义动作时，还堵塞其他信号

可以看到，在执行自定义动作时，3，4，5信号虽然接收到了，但是因为阻塞，所以无法递达。

结束语

本篇内容到此就结束了，感谢你的阅读!

如果有补充或者纠正的地方，欢迎评论区补充，纠错。如果觉得本篇文章对你有所帮助的话，不妨点个赞支持一下博主，拜托啦，这对我真的很重要。