Linux系统编程:信号的发送、保存和处理
事实上,由于UNIX 的历史原因,要想不产生僵尸进程还有另外一种办法:父进程调 用sigaction将SIGCHLD的处理动作 置为SIG_IGN,这样fork出来的子进程在终止时会自动清理掉,不会产生僵尸进程,也不会通知父进程。系统默认的忽略动作和用户用sigaction函数自定义的忽略通常是没有区别的,但这是一个特例。此方法对于Linux可用,但不保证 在其它UNIX系统上都可 用。请编写程序
一、信号的发送
什么是信号的发送??
与其说是给进程发送信号,倒不如说是给进程的PCB结构体发信号
1、比特位为0或者为1,表明是否收到。
2、比特位的位置是第几个,表明的是信号的编号。
3、所谓的“发信号”,本质就是OS去修改task_struct的信号位图对应的比特位。所以其实是“写信号”!!
——>这也就是为什么信号必须由OS发送,因为OS是进程的管理者!!只有它才有资格修改task_struct内的属性!!
问题:PCB内部采用位图来接受普通信号,可是如果我发送了很多次相同的信号呢??你的位图是能保存一次怎么办??
——> 本来这种设计方案就只能保存1次,假设你一直没能处理该信号,而又接受了很多次该信号,那么其实也只能算一次,其他的就会丢失掉。这就好比你妈喊你吃饭,不管他喊了你多少次你没有下去,但是最终你其实都是会下去吃饭的, 而如果是实时信号,就必须得立即处理了,发了几次就得执行几次,不能丢失!!
二、信号的保存
为什么需要有信号保存??
——>因为进程收到信号后,可能不会立即处理这个信号,所以就需要有一个时间窗口
2.1 信号的一些相关概念
1、实际执行信号的处理动作称为 信号递达 (handler表)
2、信号从产生到递达之间的状态,叫做 信号未决 (pending表)
3、进程可以选择阻塞某个信号 (block表)
4、被阻塞的信号产生时将保存在未决状态,直到进程解除对此信号的阻塞,才执行递达的动作
5、阻塞和忽略是不同的(未读和已读不回),只要信号被阻塞就不会递达,而忽略是递达之后可以选择的一种处理动作!!
2.2 内核中的表示
进程内部有关信号部分维护了3张表,block表(被阻塞的信号)和pending表(接受但未处理的信号)是位图结构,而handler表是函数指针数组表示处理动作。
SIG_DFL : 默认动作
SIG_IGN:忽略
而如果我们用户捕获信号设置了自定义方法,就可以将该方法的函数指针填到handler表中!
2.3 sigset_t
三张表都是OS内部的内核数据结构,所以你用户想读或者是想改就必须由系统调用接口!! 关键是获取这些表也存在位图,所以这也就意味着我们需要在用户层和内核层之间进行数据拷贝(参数设计上需要有输入型参数和输出型参数)。然后他就设计出了一个信号集数据类型sigset_t ,本质上就是被封装起来的位图结构。
问题:为什么要这样设计呢??sigset_t本质上部就是一个unsigned int类型吗??
——>(1)这样设计后期更具有拓展性 (2)防止你随意进行位操作 (3)跨平台保证可移植性
2.4 信号集操作函数
2.5 sigprocmask和sigpending
调用函数sigprocmask可以读取或更改进程的信号屏蔽字(阻塞信号集)。
sigpending:读取当前进程的未决信号集(pending),通过set参数传出。
尝试屏蔽2号信号 打印pending表
尝试先屏蔽2号信号 然后再解除
问题:那我们如果将所有的信号都进行屏蔽,信号不就不会被处理了么??
——>OS在忽略的时候对9和19号信号防了一手,那么自然就也会在屏蔽信号这里防止9和19号被屏蔽!!
三、信号处理
信号是什么时候被处理的??
——>当我们的进程从内核态返回到用户态的时候,进行信号的检测和处理!!
3.1 重谈进程地址空间
解析:
(1)我们之前所谈到的进程地址空间大多数谈的都是用户区,但是从3GB——4GB的位置是内核区,内核区也有一张自己的内核级页表。映射到OS的代码和数据(打开OS的时间就预先加载起来了)
(2)调用系统调用的本质就是OS自动做“身份切换”,从用户态进入内核态,转化为汇编叫做int 80 (陷入内核)
问题1:我怎么知道当前访问的是用户层还是内核层??
——>CR3寄存器存储的是页表的地址,而ecs寄存器中有两个bit位表示当前处于内核态还是出于用户态(00表示内核态 11表示用户态) 用来帮助OS判断当前访问了什么态,如果当前是用户态但是却访问了操作系统的代码和数据,就会拦截你!
问题2:用户页表有几份?内核页表有几份??
——>用户页表,有几个进程就有几份,因为进程具有独立性,而内核级页表只有一份!!
——>说明每一个进程看到的3-4GB的东西都是一样的!!整个系统中进程再怎么切换,3-4GB映射的内容是不变的!!
问题3:进程和OS的视角是怎样的?
——>(1)进程视角:我们调用系统重的方法,就是在我自己的地址空间中进行的!
(2)OS视角:任何时刻都有进程执行,我们想执行OS代码就可以随时调度去执行!!
问题4:OS调度进程的执行,可OS也是一个进程啊,那谁来调度他呢??他的本质是什么??
——>操作系统的本质是基于时间中断的一个死循环!!
——>在计算机硬件中,有一个时钟芯片,每隔很短的时候,向计算机发送时钟中断。由该硬件来督促OS的执行
问题5:时间芯片是如何督促OS的??
——>首先OS在被启动的时候,必然会先初始化一些必须的资源。在那以后他就会在那不断调用pause函数在那等芯片每隔一段时间来驱动自己!!
——>每当时钟响了以后(芯片发送时间中断信号),OS就会执行一些被规定好的检查工作,比如说看看当前正在被调度的进程的时间片是否到了,如果到了就把他从cpu上剥离下来!!
——>所以外部的设备的中断不一定会出现(跟外设做数据的交互),但是时钟中断必然每隔一段时间就会来一次(进行进程调度或者是其他检查工作)
3.2 信号的处理全过程示意图
存在2种情况
情况1(没有设置自定义方法):用户态(执行常规指令)——>内核态(遇到系统调用或者中断、异常之后陷入)——>用户态(返回用户态之前,处理一下当前的信号,因为是内置的方法 所以顺便处理完了正好出来 从中断的地方继续执行 )
情况2(没有设置自定义方法):用户态——>内核态——>用户态(和之前不同的是,这次自定义的方法在用户态,所以必须要先出去)——>内核态(自定义方法调用完后会自动通过sigreturn返回内核 响应信号)——>用户态(返回上次中断的地方继续执行)
问题: 通过系统调用、中断、异常进入内核态我可以理解,可如果我就是一个while循环里面也没有任何系统调用,那我是不是就不会进入内核态了??
——> 不是!! 千万要记住不光光只有系统调用、中断、异常会进入内核态,还有时钟芯片定期驱动OS!!进程是会被调度的!! 当你时间片到了被检测到的时候,你这个进程就会从cpu上被剥离下来,然后该进程的PCB会被暂时链入到等待队列中,上下文信息也会暂时被保存起来,而当你二次调度的时候必然需要将一些上下文信息恢复到cpu上,所以这个过程必然会进入到内核态中!!
——>所以我们会有无数次机会从用户态到内核态!!不用担心处理不了信号!!
3.3 信号的处理方法
sigaction函数可以读取和修改与指定信号相关联的处理动作。调用成功则返回0,出错则返回- 1。
sa_handler是方法
问题1:pending位图是什么时候从1->0的??
——>先清0,再调用
验证方法: 捕捉信号后,然后在自定义的方法里打印pending表
问题2:信号被处理时,对应的信号也会被添加到block表中,防止信号捕捉被嵌套使用
——> 正在处理2信号的时候,会将2信号的block表屏蔽掉,这样保证在处理2信号的时候,新的2信号不可被递达, 意思就是必须要等到这个2号处理完,才能处理新的2号!!
——> 这是为了防止OS一直忙于某种信号的处理,从而引发的嵌套调用(因为自定义函数里可能会再次发送该信号)
——>比方说我们再准备捕捉2号信号之前,我们是先把pending由1->0,然后当我们进入自定义函数的时候还是有可能接受到新的2信号,pending由0->1,而此时如果再进入内核态,那么从内核态出去用户态的时候,当前的2都还没处理完呢,又检测到pending表的1然后接着处理新的2号,此时就会陷入处理2号信号的死循环!!
验证方法:故意在handler方法里写个死循环(意思就是捕获之后就不返回了),这样当我们第二次发送2号信号的时候,那么该信号就会被阻塞到pending表中,我们再打印出来看即可!
问题3:as_mask是什么??
——>as_mask是存放需要手动屏蔽的信号!!
——>比如当前我们处理2号信号的时候,他会顺便把所有sa_mask里面bit位为1的信号也顺带屏蔽了!
四、信号所引发的其他子问题
信号具有从当前执行流直接跳转到别的执行流的能力,因此可能会引发以下的一些子问题
4.1 可重入函数
下图出问题的原因就是:本来insert应该是main函数的执行流里调用的,但(1)insert还没调用完呢就跳转过去执行信号捕捉sighandle了,此时sighandle这个执行流又再次调用了insert,此时insert这个函数被重复进入了!! 加上(2)访问的链表是全局的链表(如果是局部的不会错乱)所以就会因为重入引发错乱!!造成了节点丢失,内存泄漏
问题1: 如果一个函数符合以下条件之一则是不可重入的
——>(1)调用了malloc或free,因为malloc也是用全局链表来管理堆的。
(2)调用了标准I/O库函数。标准I/O库的很多实现都以不可重入的方式使用全局数据结构。
问题2: 什么情况下一个函数会被多次进入??
——>(1)以前学cpp的时候都是单执行流,如果是多执行流的话就有可能一个函数被多个执行流进入(多进程)
(2)如上图一样,虽然只有一个进程,但是main函数和sighanle函数其实并没有调用和被调用的关系,他们是并列的关系,属于不同的执行流,前者是必然执行的,而后者是否执行取决于是否收到信号,如果收到了就会暂时停止main函数,等sighanle函数执行完了才会回来执行main ——>所以重入发生在当main恰好在调用一个函数还没返回的时候,突然停下来去捕获信号,而该信号恰好也调用了这个函数。
问题3:为什么目前大部分的函数都是不可重入函数??
——>因为我们大部分使用的函数都可能会涉及到一些容器, 比如扩容,就会相互影响!!
4.2 解决过度优化的volatile
我们来看看下面的代码
这个代码按道理是个死循环不会退出,但如果flag是全局变量,我们就可以在中途通过捕捉信号来把他的值修改一下,那么就会退出了!!
但是这种情况是有可能会被做优化的:因为main和handler是两个执行流,所以当cpu发现main函数内部不对flag做修改而只是单纯读取并做逻辑运算的时候,综合以上两个条件他就会直接把flag变量优化到CPU内寄存器中方便后续的操作(通过减少数据的拷贝来提高效率),这样的话如果你再去修改flag,那你修改的就是内存里面的flag而不是进程里面的flag!!
Linux的优化方案设计:
我们会发现优化方案为O1的时候,此时flag就被优化了!!
因为优化导致我们的内存不可见了!!
解决方案就是用:
volatile关键字: 保持内存的可见性,告知编译器,被该关键字修饰的变量,不允许被优化,对该变量 的任何操作,都必须在真实的内存中进行操作!!
与他相反的关键字:
register建议型关键字:当前修饰的变量能放在寄存器中就放在寄存器中!!
4.3 基于信号的异步等待方案
子进程在退出的时候,他并不会悄悄退出,而是在退出的时候会主动向父进程发送SIGCHLD(17)信号
验证:
既然子进程退出的时候会收到信号,那我不如等收到信号再回收,这样不就避免傻傻等待了吗?
所以我们可以把等待子进程的函数写到信号捕捉的函数里!!
问题1:可是假如有10个进程同时退出呢??你在处理1个进程的时候信号可是会被阻塞的,那就会导致8个进程的信号丢失了!!这要怎么办??
——>所以我们可以尝试在收到1个信号的时候,就开始一直尝试回收。
问题2:可是如果我们当前10个进程,只是退出一半,而另一半还得继续运行呢??那么父进程在收到信号时发现进程没有全部退出,他就会卡在信号捕捉函数里阻塞起来了,该怎么办??
——>解决方法就是采用非阻塞轮询!!
因此,将回收子进程的过程放在信号捕捉函数里,并采用非阻塞轮询,可以大大提高等待的效率!
问题3: 那么以前我们并不知道有这种方案的时候,子进程向父进程发送信号,那父进程的默认动作究竟是什么??
——> SIGCHLD信号的默认动作是忽略,所以就是相当于什么都没做!
问题4:子进程会变成僵尸进程因为父进程想关心父进程的退出状态,所以他才会在那等待父进程回收,可是如果我压根就不想关心子进程的退出状态呢??我可不可以让OS直接帮我回收呢??
——>事实上,由于UNIX 的历史原因,要想不产生僵尸进程还有另外一种办法:父进程调 用sigaction将SIGCHLD的处理动作 置为SIG_IGN,这样fork出来的子进程在终止时会自动清理掉,不会产生僵尸进程,也不会通知父进程。系统默认的忽略动作和用户用sigaction函数自定义的忽略通常是没有区别的,但这是一个特例。此方法对于Linux可用,但不保证 在其它UNIX系统上都可 用。请编写程序验证这样做不会产生僵尸进程。父进程就不需要wait了!
问题5: 以前的默认动作就是忽略,那为什么我们把他捕获后再设成忽略就没有僵尸了??这到底是怎么区分的??
——>其实看起来都是忽略,但根本不一样!!其实原本是SIG_DFL,只不过他的方法恰好就是忽略而已,而我们捕获后把他改成SIG_IGN就可以区分开了!! 这样就是一种特殊的方式告诉OS你直接把子进程给回收吧,我不打算关心子进程的状态!!
更多推荐
所有评论(0)