signals 与进程通知
这页讲的是：进程并不总是按自己手上的主线剧情稳稳往前跑，很多时候系统或别的进程需要在运行中插一句“停一下”“你子进程结束了”“你碰了不该碰的地址”“你该退出了”。学这页的重点，是理解 signal 更像内核和进程之间的一套异步通知机制，而不是单纯某个 API 名字。
这块是什么
signals 与进程通知，讲的是 Linux 怎样把“外部事件、控制意图或执行异常”正式送到目标进程或线程手里，让对方在合适时机感知、处理中断、终止、继续执行或运行用户自定义处理逻辑。它一头连着异常、终端控制、进程关系和系统管理，一头连着任务状态、返回用户态时机和用户程序行为。
可以把它理解成：进程正在埋头干活，系统或者别人可以递来一张正式通知单。通知单上可能写着“暂停”“继续”“你家孩子结束了”“你刚才撞墙了”“请准备退出”。
它负责什么
异步打断或提醒进程
- 让系统不用等进程主动轮询就能正式通知它
- 用于终止、暂停、继续、提醒子进程状态变化等场景
- 把运行中的“插话”变成一套标准机制
- 让控制和异常反馈能穿到进程执行路径里
承接异常结果
- 非法访问、非法指令等执行异常常会落成进程可见后果
- 让硬件或内核检测到的问题传到用户程序边界
- 不是所有错误都变成返回值
- 有些失败是以“你被打断/终止”的形式到达
表达进程控制关系
- 父子进程、终端、运维工具都可能借它影响任务状态
- 支撑 kill、Ctrl+C、后台作业管理等常见行为
- 让进程不只是自己向前跑，还活在系统关系网里
- 把控制语义从私有约定变成正式接口
为什么它不是“高级一点的返回码”
| 如果想得太简单 | 会怎样 | 真正关键在哪 |
|---|
| 把 signal 当成普通函数结果 | 会忽略它是异步到达、可能在别的时刻打断执行。 | 它不是主流程里顺着返回的结果，而是运行期插入的通知。 |
| 觉得只有 kill 才和 signal 有关 | 会错过异常、终端控制、子进程状态也都在用它。 | 它承接的是很广的一类进程通知语义。 |
| 把 signal 只理解成“结束进程” | 会忽略暂停、继续、忽略、捕获、自定义处理等不同结果。 | 它更像通知机制，不同信号和处理策略带来不同后果。 |
| 觉得通知到了就算完 | 会漏掉线程选择、屏蔽、挂起、何时真正递送这些运行时细节。 | 异步通知的难点就在“什么时候、送给谁、那时能不能处理”。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| signal | 一套用来向进程或线程传递异步通知的正式机制。 |
| 递送 | 不是产生了就立刻执行，而是最终在哪个时机真正交到目标执行路径手里。 |
| 屏蔽 / 挂起 | 某些信号可以暂时不处理，先挂在那里，等合适时机再递送。 |
| 默认动作 | 不同信号如果不自定义处理，会有系统预设后果，比如终止、忽略、暂停。 |
| 信号处理函数 | 用户程序可以为部分信号注册自己的处理逻辑。 |
| 同步异常 / 异步通知 | 有些信号源自当前执行本身出了问题，有些则来自外部控制或别的实体。 |
为什么重要
- 它解释了为什么进程管理不是只有系统调用返回值，很多关键状态变化是以异步通知形式进入程序世界的。
- 很多你日常熟悉的行为，如 `Ctrl+C`、子进程退出通知、非法访问导致程序终止，本质上都离不开 signal。
- 理解这层后，你会更容易把异常、任务状态、进程关系和用户态控制流串在一起。
- 它让你看到：程序并不是完全封闭的单线剧情，而是随时可能被系统关系网打断、提醒或终止。
常见误解
- 误解一：signal 只是命令行里 `kill` 那个动作。实际上它远不止人工发通知，还承接异常和系统状态变化。
- 误解二：收到信号就一定马上执行处理函数。实际上还要看屏蔽状态、线程上下文和返回用户态时机。
- 误解三：信号只是用户程序层面的技巧。实际上它深深连接着调度、中断后的结果、异常和进程生命周期。
它不负责什么
- 它不替代普通数据通信；大量结构化数据交换通常不该靠 signal 承担。
- 它不保证复杂逻辑安全执行；异步处理天然受上下文和可重入性约束。
- 它不等于所有事件机制；文件描述符就绪、netlink 消息、共享内存同步等各有自己的路径。
和其他模块的关系
| 相关模块 | 关系 |
|---|
| 进程、线程与任务模型 | 信号最终要落到具体任务关系里，所以它天然依赖进程/线程世界观。 |
| page fault 与异常路径 | 某些执行错误并不会只留在内核内部，而会继续变成进程可见的信号结果。 |
| 调度器与等待 | 任务睡眠、可中断等待、被打断返回，都常和信号到达时机连在一起。 |
| 系统调用与用户空间边界 | 系统调用可能被信号打断，内核也常在返回用户态前完成信号递送。 |
| futex 与用户态同步 | 很多用户态等待不仅要考虑唤醒，还得考虑是否会被信号中断。 |
读完这页后，你应该能回答
- 为什么 signal 更像一套异步通知机制，而不只是一个“结束进程”的工具？
- 为什么异常、终端控制、父子进程状态这些看似不同的事情，常能落到同一类通知模型里？
- 为什么信号问题常常和任务状态、系统调用中断以及返回用户态时机绑在一起？
后面适合继续问：signal 和普通返回错误最容易混在哪？哪些等待会被信号打断，为什么这会改变用户程序的控制流？同步异常和异步通知都叫 signal，但两者的“来源感”到底差在哪？