目录
信号保存的本质
一些概念
信号递达
进程实际执行信号的处理动作
信号未决
信号从产生->递达的中间状态
- 之前有说过,信号产生后(也就是os修改了信号位图),进程并不会立即执行相应的处理动作,而是等到合适的时候再处理
- 这个等待的过程中,信号的状态就被叫做信号未决
信号阻塞
引入
- 虽然并不会立即执行,但进程终究是会处理产生的信号的
- 但如果我们有一些不想让进程处理的信号呢?
- 因为可能存在这样的场景,所以我们就有了"阻塞"的概念
- 可以让产生的信号不会被处理
注意点
[不会被处理]和 [处理方式中的忽略]的结果相似,都是不会有什么操作
但是!!!本质不同
- "忽略"这个处理方式,最终还是处理了的,也就是信号会被递达的
- 但不会处理,就是信号永远保持未决状态,而不会被递达
介绍
- 进程可以选择阻塞某个信号
- 被阻塞的信号产生时将保持未决状态,直到进程解除该信号的阻塞,才执行递达动作
信号在内核中的数据结构
引入
信号在内核中实际上有三种结构进行表示
而我们前面一直在说的信号位图,实际上是其中的pending位图
介绍
其中:
- pending位图 -- 用于标识信号是否产生
- handler -- 中存放对应的信号处理方法
- block位图 -- 标识该信号是否被阻塞
handler结构
- 是一个存放函数指针的数组,数组下标作为信号索引
- 只要有信号编号,就能拿到对应的处理方法
两种处理方式(宏)
介绍
- 上面的图中,存放了两种处理方式(默认和忽略),但他俩是特殊的函数指针:
原因
- 这里将 0 和 1 进行强转,来作为信号的处理方式,是为了将默认操作和忽略操作单独拎出来
- 当我们想要将某个信号的方法改为默认/忽略时,可能会不知道该如何修改
- 需要使用os提供的接口才行,而这里的强转就是那个接口
- 它会在处理信号时,拿到指针后先进行判断(强转回整型)
- 如果是0/1,就进行相应的处理 ; 如果不是,就直接调用handler中的指针
了解结构后,我们就可以大概模拟出处理信号的过程了
模拟处理信号的过程
- 当我们准备处理信号时,首先找到pending位图中为1的下标,该下标就是信号编号
- 然后继续拿着该下标,访问block位图,查看它是否被阻塞
- 如果没有被阻塞,才去handler数组中,拿到handler中存放的指针
- 但是,拿到指针后,并不是立即执行,需要进行判断
- (因为有可能这个指针,是通过整数强转来的,而不是一个真正的函数指针)
- 当判断它不为1/0时,才会拿着这个指针进行函数调用:
sigset_t
引入
- 上面我们只说了block和pending是位图结构,但具体类型是什么呢?总不会是使用c++中的位图结构吧
- 首先我们要明确,这里的位图概念用于管理信号,是内核级的数据结构
- 就像语言库提供给我们的接口和类型一样,os也会提供一些接口和类型
- eg:之前在fork函数中的返回值pid_t,共享内存中key值的类型是key_t
- 所以,os为我们提供了它自己的位图结构sigset_t,也提供了一系列接口用来操作sigset_t
介绍 -- 信号集
sigset_t类型在<signal.h>头文件中
sigset_t被叫做信号集,用于标识每个信号的"有效"和"无效"状态
- 在不同的功能下,有效和无效的意义也不同:
- 比如上面介绍的block位图,应该叫做阻塞信号集/当前进程的信号屏蔽字(signal mask)
- 用于标识信号是否被阻塞(有效 -- 被阻塞,无效 -- 不被阻塞)
- 上面的pending位图,应该叫pending信号集
- 用于标识信号是否产生(有效 -- 产生了,无效 -- 没有产生)
接口
3893
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
