Linux 信号机制--续1

一、信号的核心数据结构

每个进程的 PCB（task_struct）里维护着三张核心表，它们共同决定了信号的处理流程：

表	作用	类比
block（阻塞信号集）	记录哪些信号被屏蔽	权限里的 umask
pending（未决信号集）	记录收到了哪些信号	待办事项清单
handler（信号处理表）	记录每个信号的处理方式	函数指针数组

这三张表都是 64 位的位图 （sigset_t 类型），每个比特位对应一个信号编号：

block 表：某位为 1 表示该信号被屏蔽（暂时不处理）
pending 表：某位为 1 表示已收到该信号（等待处理）
handler 表：存的是函数指针（SIG_DFL、SIG_IGN 或自定义函数）

信号能否被处理，取决于：

复制代码

信号被处理的条件 = pending 位为 1 && block 位为 0

二、信号的三个核心阶段

阶段	描述	涉及的表
信号产生	事件发生，OS 将 pending 表中对应位置 1	pending
信号保存	信号停留在 pending 状态，可能被阻塞	pending、block
信号递达	进程真正执行信号处理动作	handler

每个信号都有两个标志位分别表⽰阻塞(block)和未决(pending),还有⼀个函数指针表⽰处理动作。信号产⽣时,内核在进程控制块中设置该信号的未决标志,直到信号递达才清除该标志。在上图的例⼦中,SIGHUP信号未阻塞也未产⽣过,当它递达时执⾏默认处理动作。
SIGINT信号产⽣过,但正在被阻塞,所以暂时不能递达。虽然它的处理动作是忽略,但在没有解除阻塞之前不能忽略这个信号,因为进程仍有机会改变处理动作之后再解除阻塞。
SIGQUIT信号未产⽣过,⼀旦产⽣SIGQUIT信号将被阻塞,它的处理动作是⽤⼾⾃定义函数sighandler。

如果在进程解除对某信号的阻塞之前这种信号产⽣过多次,将如何处理?POSIX.1允许系统递送该信号⼀次或多次。Linux是这样实现的:常规信号在递达之前产⽣多次只计⼀次,⽽实时信号在递达之前产⽣多次可以依次放在⼀个队列⾥。

三、信号屏蔽字的操作

从上图来看,每个信号只有⼀个bit的未决标志, ⾮0即1, 不记录该信号产⽣了多少次,阻塞标志也是这样表⽰的。因此, 未决和阻塞标志可以⽤相同的数据类型sigset_t来存储, sigset_t称为信号集，这个类型可以表⽰每个信号的"有效"或"⽆效"状态, 在阻塞信号集中"有效"和"⽆效"的含义是该信号是否被阻塞, ⽽在未决信号集中"有效"和"⽆效"的含义是该信号是否处于未决状态。阻塞信号集也叫做当前进程的信号屏蔽字(Signal Mask),这⾥的"屏蔽"应该理解为阻塞⽽不是忽略。

复制代码

sigset_t类型对于每种信号⽤⼀个bit表⽰"有效"或"⽆效"状态, ⾄于这个类型内部如何存储这些
bit则依赖于系统实现, 从使⽤者的⻆度是不必关⼼的, 使⽤者只能调⽤以下函数来操作sigset_ t变量
，⽽不应该对它的内部数据做任何解释, ⽐如⽤printf直接打印sigset_t变量是没有意义的。

sigset_t 是信号集类型，不能直接操作，必须用专门的函数：（此处只是在用户层面上设置一个sigset_t类型的变量而已，并未对Block表进行修改）

复制代码

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); // 判断是否包含

更改进程的屏蔽字：`sigprocmask`

复制代码

int sigprocmask(int how, const sigset_t *set, sigset_t *oset);

how 参数	含义	数学表示
`SIG_BLOCK`	将 set 中的信号加入屏蔽字	`mask = mask
`SIG_UNBLOCK`	将 set 中的信号从屏蔽字移除	`mask = mask & ~set`
`SIG_SETMASK`	直接用 set 替换屏蔽字	`mask = set`

oset 非空时，返回旧的屏蔽字
如果解除阻塞时，有信号已经在 pending 中，sigprocmask 返回前至少递达其中一个

四、信号处理函数表

signal 函数操作的是 handler 表：

handler 表里可以存三种值：

SIG_DFL：默认处理（通常是终止进程）
SIG_IGN：忽略信号
函数指针：自定义处理函数

五、硬件异常如何产生信号

1. 除零异常（SIGFPE，8 号）

CPU 执行除法时，若除数为 0，结果无法表示 → 硬件将状态寄存器（EFLAGS）的溢出标志位置 1 → CPU 触发异常 → 内核发 SIGFPE

2. 野指针异常（SIGSEGV，11 号）

访问非法内存地址时，MMU 会检查虚拟地址是否合法 ，如果不合法，会将出错地址存入 CR2 寄存器并触发异常 → 内核发 SIGSEGV

注意：野指针不一定每次都崩溃------如果乱指的地址恰好是合法的（比如越界到另一个变量），就不会触发硬件异常。

异常信号的处理流程

复制代码

CPU 执行指令 → 硬件检测到异常 → CPU 保存上下文 → 跳转内核
→ 内核通过 current 指针找到当前进程
→ 查看进程的 handler 表
   ├─ 默认动作 → 直接终止
   └─ 有自定义 handler → 恢复上下文让进程执行 handler

这里有一个经典问题：如果 handler 返回后没有修复异常原因，CPU 会重新执行同一条指令，再次触发异常，形成死循环。

六、信号产生的方式

产生方式	举例	说明
键盘产生	Ctrl+C（SIGINT）、Ctrl+\（SIGQUIT）	终端驱动发信号
kill 命令	`kill -9 1234`	调用 kill 系统调用
系统调用	`kill()`、`raise()`、`abort()`	主动发信号
软件条件	SIGPIPE、SIGALRM（alarm）	内核检测到特定条件
硬件异常	除零、野指针	CPU/MMU 触发
外设中断	键盘有输入、网卡有数据	硬件中断→中断向量表→OS 发信号

补充：硬件中断与信号的关系

外设（键盘、磁盘、网卡）准备好数据后，会向 CPU 发送硬件中断 （高电频信号）。

CPU 收到中断后，会去查中断向量表 （一个函数指针数组，每个外设对应一个处理函数），执行对应的中断处理程序，将数据读到内存。

这个过程是 OS 不主动轮询外设的基础------这也是"信号产生方式很多，但最终面对进程的一定是 OS"的原因。

七、Core Dump 与 Term 的区别（扩展知识）

信号的默认动作有两种常见类型：

Term：直接终止进程，不留下任何痕迹，这种属于正常终止，比如用户要求终止
Core：终止进程，并生成 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 7（3.10 内核）：core.pid
- Ubuntu 22.04（5.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，失败 -1
`raise(sig)`	给自己发信号	等价于 `kill(getpid(), sig)`
`abort()`	给自己发 SIGABRT（6 号）	即使被捕捉，handler 后仍会终止
`alarm(sec)`	设置闹钟，到期发 SIGALRM（14 号）	一个进程只能有一个闹钟
`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 让进程可以主动等待信号，避免空转

Linux 信号机制--续1

一、信号的核心数据结构

二、信号的三个核心阶段

三、信号屏蔽字的操作

更改进程的屏蔽字：sigprocmask

四、信号处理函数表

五、硬件异常如何产生信号

1. 除零异常（SIGFPE，8 号）

2. 野指针异常（SIGSEGV，11 号）

异常信号的处理流程

六、信号产生的方式

补充：硬件中断与信号的关系

七、Core Dump 与 Term 的区别（扩展知识）

信号的默认动作有两种常见类型：

Core Dump 的作用

查看与设置 core 文件大小

云服务器默认关闭 core 的原因

Core 与 Term 的本质区别

用 gdb 调试 core 文件

八、让进程等信号：pause

pause 的作用

典型用法

为什么需要 pause？

九、信号相关的系统调用

十、总结一波

更改进程的屏蔽字：`sigprocmask`