前言
在【Linux】进程信号及信号产生中,我们提到,进程接收到信号,并不是立刻处理,而是在合适的时候才执行相应的动作,那合适的时候是什么时候呢,进程捕捉信号的过程究竟是怎么样的呢?本篇博客就来一一讲解
文章目录
- 前言
- 一. 合适的时候
- 二. 内核态 / 用户态
- 三. 进程调度
- 四. 状态切换
- 五. 信号捕捉
- 结束语
一. 合适的时候
首先,进程信号一般
都不是立刻处理的,但也可以立刻被处理:
当一个信号之前处于阻塞(block)状态,那么当阻塞状态解除后,该信号会被立刻递达,处理
因为信号的产生对于进程来说是异步的,可能信号产生时,当前进程正在做一些优先级高的任务
,那么此时就需要将当前任务做完,才处理信号。所以信号不是都立刻处理的
那么什么时候才是合适的时候呢?
OS规定,当进程从 内核态
切换到 用户态
时,进程会在OS的指导
下,进行信号的检测和处理
二. 内核态 / 用户态
用户态
:执行我们自己写的代码
的时候,进程所处的就是用户态。
内核态
:执行OS的代码
的时候,进程所处的就是内核态。
用户态我们可以理解,但是内核态的OS的代码是什么意思呢?
进程时间片到了
,需要切换进程,就要执行进程切换逻辑
系统调用
:sleep,C/C++的printf和cout,内部都封装了和键盘,显示器交互的系统调用
这些都是OS的代码。
这里我们还需要引入一些虚拟地址空间
- 其中,
[0,3]GB是用户空间
,其中的代码和数据会通过用户级内标
映射到物理内存[3,4]GB是内核空间
,其中的代码和数据会通过内核级页表
映射到物理内存。- 在电脑开机,启动Linux时,其实就是将OS的代码和数据
加载到物理内存中
- 每个进程的
用户空间并不相同
,但是内核空间是一样的
,每个进程都有自己的用户级页表
,但是每个进程看到的都是同一个内核级页表
,这样所以进程都可以通过统一的窗口,看到同一个OS
所以,用户态,其实就是访问用户空间的代码和数据
;而内核态,则是访问内核空间的代码和数据
系统调用的本质,就是从用户空间,进行函数跳转到内核空间,执行相应方法,最后再返回用户空间
但是这就引发一个问题:那这样我们会不会就可以直接访问OS的代码?
答案肯定是不行。
为了防止我们访问,就划分出了用户态和内核态
在CPU中,有一个CR3寄存器
。
内部如果标记为3
:表征正在运行的进程执行级别是用户态
内部如果标记为0
:表征正在运行的进程执行级别是内核态
而在所有的OS提供的系统调用,内部在正式执行调用逻辑前,都会去修改执行级别
如果用户去访问内核空间,CPU会先检查到要访问[3,4]空间,进而检查当前进程的执行级别,发现是3,用户态时,就会将非法访问寄存器
标记为1,进而产生硬件中断
,OS检测到硬件中断,就会给当前进程发送终止信号
而OS无法仅靠内核空间管理软硬件,他自己也有进程:1号进程就是OS的进程
三. 进程调度
有了虚拟地址空间的了解,我们还需要了解进程调度
,理解时间片
时间片
时间片就是一个进程获得CPU资源的时间
首先,OS是一个软件,本质是一个死循环
,会一直检测有没有收到中断
计算机有一个硬件,叫晶体震荡器
,即使电脑关机,这个硬件依然做着记录时间
的工作。
该硬件会在很短的时间内,给OS发送时钟中断
,OS就要执行对应的中断方法。
这个中断方法就包括检测当前进程的时间片
进程的pcb会记录进程被调度的时间,OS可以凭借时钟,判断当前进程的时间片是否结束。
如果时间片到了,会保存上下文(执行到哪),代码,数据,然后切换到另一个进程
这些操作其实都是一个系统调用——schedule()
而因为用户空间和内核空间都在一起,其实就相当于当前进程自己切换了进程。
检测时间片,切换进程等其实都是在当前进程中进行的,OS会在当前进程的上下文运行
四. 状态切换
有了以上的知识储备,我们要分析一下一个进程运行的状态切换。
我们用这个图辅助理解
- 首先,我们是运行用户代码,而一旦使用
系统调用函数
,或者时间片到达
(本质也是使用系统调用函数),就会切换到内核态
- 切换到内核态完成系统调用后,在
切换回用户态之前
,会进行信号检测
的系统调用。检测当前进程的pengding表,block表。一旦pengding表的一个比特位为1,block表相应比特位为0,代表收到该信号,则进行handler表内相应方法的执行:执行方法有三种:1.SIG_DFL(
默认动作
,终止进程) 2. SIG_IGN(忽略
)3.自定义动作
。
其中SIG_DFL和SIG_IGN都是系统调用,不用切换,但是自定义动作就需要切换到用户态
执行用户提供的方法
- 如果是
自定义信号捕捉动作
,则需要切换到用户态
,执行相应方法,再切换到内核态
。因为最开始从用户态切换到内核态时,上下文是保存在内核中的
,用户并不知道,所以无法在执行自定义动作后直接继续执行原先用户的代码,还需要再切换到内核态。切换的函数是sigreturn()
- 自定义动作执行完成后,切换回内核态,再继续
检查是否还有别的信号
,最后再调用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信号虽然接收到了,但是因为阻塞,所以无法递达。
结束语
本篇内容到此就结束了,感谢你的阅读!
如果有补充或者纠正的地方,欢迎评论区补充,纠错。如果觉得本篇文章对你有所帮助的话,不妨点个赞支持一下博主,拜托啦,这对我真的很重要。