一、信号的核心数据结构每个进程的 PCBtask_struct里维护着三张核心表它们共同决定了信号的处理流程表作用类比block阻塞信号集记录哪些信号被屏蔽权限里的 umaskpending未决信号集记录收到了哪些信号待办事项清单handler信号处理表记录每个信号的处理方式函数指针数组这三张表都是64 位的位图sigset_t类型每个比特位对应一个信号编号block 表某位为 1 表示该信号被屏蔽暂时不处理pending 表某位为 1 表示已收到该信号等待处理handler 表存的是函数指针SIG_DFL、SIG_IGN 或自定义函数信号能否被处理取决于信号被处理的条件 pending 位为 1 block 位为 0二、信号的三个核心阶段阶段描述涉及的表信号产生事件发生OS 将 pending 表中对应位置 1pending信号保存信号停留在 pending 状态可能被阻塞pending、block信号递达进程真正执行信号处理动作handler每个信号都有两个标志位分别表⽰阻塞(block)和未决(pending),还有⼀个函数指针表⽰处理动作。信号产⽣时,内核在进程控制块中设置该信号的未决标志,直到信号递达才清除该标志。在上图的例⼦中,SIGHUP信号未阻塞也未产⽣过,当它递达时执⾏默认处理动作。SIGINT信号产⽣过,但正在被阻塞,所以暂时不能递达。虽然它的处理动作是忽略,但在没有解除阻塞之前不能忽略这个信号,因为进程仍有机会改变处理动作之后再解除阻塞。SIGQUIT信号未产⽣过,⼀旦产⽣SIGQUIT信号将被阻塞,它的处理动作是⽤⼾⾃定义函数sighandler。如果在进程解除对某信号的阻塞之前这种信号产⽣过多次,将如何处理?POSIX.1允许系统递送该信号⼀次或多次。Linux是这样实现的:常规信号在递达之前产⽣多次只计⼀次,⽽实时信号在递达之前产⽣多次可以依次放在⼀个队列⾥。三、信号屏蔽字的操作从上图来看,每个信号只有⼀个bit的未决标志, ⾮0即1, 不记录该信号产⽣了多少次,阻塞标志也是这样表⽰的。因此, 未决和阻塞标志可以⽤相同的数据类型sigset_t来存储, , 这个类型可以表⽰每个信号的“有效”或“⽆效”状态, 在阻塞信号集中“有效”和“⽆效”的含义是该信号是否被阻塞, ⽽在未决信号集中“有 效”和“⽆效”的含义是该信号是否处于未决状态。下⼀节将详细介绍信号集的各种操作。阻塞信号集也叫做当前进程的 这⾥的“屏蔽”应该理解为阻塞⽽不是忽略sigset_t类型对于每种信号⽤⼀个bit表⽰“有效”或“⽆效”状态, ⾄于这个类型内部如何存储这些 bit则依赖于系统实现, 从使⽤者的⻆度是不必关⼼的, 使⽤者只能调⽤以下函数来操作sigset_ t变量 ⽽不应该对它的内部数据做任何解释, ⽐如⽤printf直接打印sigset_t变量是没有意义的。sigset_t是信号集类型不能直接操作必须用专门的函数int sigemptyset(sigset_t *set); // 全部清 0 int sigfillset(sigset_t *set); // 全部置 1 int sigaddset(sigset_t *set, int signo); // 添加一个信号 int sigdelset(sigset_t *set, int signo); // 删除一个信号 int sigismember(const sigset_t *set, int signo); // 判断是否包含更改进程的屏蔽字sigprocmaskint sigprocmask(int how, const sigset_t *set, sigset_t *oset);how 参数含义数学表示SIG_BLOCK将 set 中的信号加入屏蔽字mask mask | setSIG_UNBLOCK将 set 中的信号从屏蔽字移除mask mask ~setSIG_SETMASK直接用 set 替换屏蔽字mask setoset非空时返回旧的屏蔽字如果解除阻塞时有信号已经在 pending 中sigprocmask返回前至少递达其中一个四、信号处理函数表signal函数操作的是 handler 表handler 表里可以存三种值SIG_DFL默认处理通常是终止进程SIG_IGN忽略信号函数指针自定义处理函数五、硬件异常如何产生信号1. 除零异常SIGFPE8 号CPU 执行除法时若除数为 0结果无法表示 → 硬件将状态寄存器EFLAGS的溢出标志位置 1 → CPU 触发异常 → 内核发 SIGFPE2. 野指针异常SIGSEGV11 号访问非法内存地址时MMU 会检查虚拟地址是否合法如果不合法会将出错地址存入CR2 寄存器并触发异常 → 内核发 SIGSEGV注意野指针不一定每次都崩溃——如果乱指的地址恰好是合法的比如越界到另一个变量就不会触发硬件异常。异常信号的处理流程CPU 执行指令 → 硬件检测到异常 → CPU 保存上下文 → 跳转内核 → 内核通过 current 指针找到当前进程 → 查看进程的 handler 表 ├─ 默认动作 → 直接终止 └─ 有自定义 handler → 恢复上下文让进程执行 handler这里有一个经典问题如果 handler 返回后没有修复异常原因CPU 会重新执行同一条指令再次触发异常形成死循环。六、信号产生的方式产生方式举例说明键盘产生CtrlCSIGINT、Ctrl\SIGQUIT终端驱动发信号kill 命令kill -9 1234调用 kill 系统调用系统调用kill()、raise()、abort()主动发信号软件条件SIGPIPE、SIGALRMalarm内核检测到特定条件硬件异常除零、野指针CPU/MMU 触发外设中断键盘有输入、网卡有数据硬件中断→中断向量表→OS 发信号补充硬件中断与信号的关系外设键盘、磁盘、网卡准备好数据后会向 CPU 发送硬件中断高电频信号。CPU 收到中断后会去查中断向量表一个函数指针数组每个外设对应一个处理函数执行对应的中断处理程序将数据读到内存。这个过程是 OS 不主动轮询外设的基础——这也是“信号产生方式很多但最终面对进程的一定是 OS”的原因。七、Core Dump 与 Term 的区别扩展知识信号的默认动作有两种常见类型Term直接终止进程不留下任何痕迹Core终止进程并生成 core 文件进程的上下文转储Core Dump 的作用当进程收到 8 号SIGFPE、11 号SIGSEGV等带 Core 标志的信号时OS 会将进程的上下文数据dump 到当前目录下的 core 文件供后续调试。查看与设置 core 文件大小ulimit -a # 查看所有限制 ulimit -c 2024 # 设置 core 文件最大 2024 KB ulimit -c unlimited # 不限制大小云服务器默认关闭 core 的原因如果设置ulimit -c unlimited每次进程崩溃都会生成 core.pid文件重启次数多了core.pid 文件会占用大量磁盘空间不同内核的命名规则CentOS 73.10 内核core.pidUbuntu 22.045.4 内核core同名文件不会无限增长只会不断替换上一个core文件Core 与 Term 的本质区别Term进程终止不 dump 上下文Core进程终止并 dump 上下文前提是ulimit -c不为 0如果ulimit -c为 0即使收到 Core 信号也不会生成 core 文件用 gdb 调试 core 文件gdb 可执行程序 core文件 # 会自动定位到出错的那一行八、让进程等信号pause进程有时候需要“主动停下来等信号来了再继续”。如果没有这种机制进程只能空转轮询浪费 CPU。pause 的作用int pause(void);调用 pause 的进程进入可中断睡眠状态S 状态不占用 CPU让出时间片直到有信号递达pause 才返回典型用法sigset_t set; sigemptyset(set); sigaddset(set, SIGINT); sigprocmask(SIG_BLOCK, set, NULL); // 先屏蔽 SIGINT // 做其他工作... sigprocmask(SIG_UNBLOCK, set, NULL); // 解除屏蔽 pause(); // 等待 SIGINT 到来为什么需要 pause让进程主动让出 CPU避免空转配合信号屏蔽字实现精确的信号等待是信号驱动编程的基础九、信号相关的系统调用函数作用说明kill(pid, sig)给任意进程发信号成功 0失败 -1raise(sig)给自己发信号等价于kill(getpid(), sig)abort()给自己发 SIGABRT6 号即使被捕捉handler 后仍会终止alarm(sec)设置闹钟到期发 SIGALRM14 号一个进程只能有一个闹钟pause()等待信号信号递达后返回 -1十、总结一波信号产生键盘/kill/系统调用/软件条件/异常/硬件中断 ↓ OS 将 pending 表对应位置 1 ↓ 检查 block 表 ├─ 若对应位为 1被阻塞→ 信号停留在 pending └─ 若对应位为 0 → 准备递达 ↓ 查 handler 表 ├─ SIG_IGN → 忽略清 pending 位 ├─ SIG_DFL → 执行默认动作Term/Core └─ 函数指针 → 执行自定义 handler返回后可能重新执行指令核心理解信号处理围绕三张表block、pending、handler对信号的操作本质上就是对这三张表的增删查改signal操作 handler 表sigprocmask操作 block 表硬件异常是信号的重要来源其处理流程涉及 CPU、MMU、内核三者的配合Core Dump 是调试的利器但云服务器默认关闭以防磁盘爆炸pause 让进程可以主动等待信号避免空转