全文目录
概念
信号与信号量是不同的概念。
什么是Linux信号？
本质上是一种通知机制，用户或者OS通过发送信号，告诉进程需要做什么。
例如：
ctrl + c本质就是向进程发送2号信号，终止进程。
- 进程要处理信号，必须具备信号"识别"的能力（看到 + 处理动作）
- 信号的处理不是立即的
- 信号会临时记录对应的信号，方便后续处理
- 一般而言，信号的产生相对与进程而言是异步的
通过kill -l 可以察看系统定义的信号列表：
1,31\]普通信号，\[34,64\]实时信号
## 信号行为（core dump）
通过`man -7 signal` **查看信号的处理动作**：
* T e r m ( t e r m i n a l ) Term(terminal) Term(terminal) 表示终止进程
* C o r e ( C o r e D u m p ) Core(Core Dump) Core(CoreDump) 表示核心转储，默认关闭。
在进程等待中也出现了这个名词：
> 首先解释什么是 C o r e D u m p Core Dump CoreDump。当一个进程要异常终止时,可以选择把进程的用户空间内存数据全部 保存到磁盘上，文件名通常是 c o r e core core,这叫做 C o r e D u m p Core Dump CoreDump。进程异常终止通常是因为有 B u g Bug Bug，比如非法内存访问导致段错误，事后可以用调试器检查 c o r e core core 文件以查清错误原因，这叫做 P o s t − m o r t e m D e b u g Post-mortem Debug Post−mortemDebug（事后调试）。一个进程允许产生多大的 c o r e core core文件取决于进程的 R e s o u r c e L i m i t Resource Limit ResourceLimit(这个信息保存 在 P C B PCB PCB 中)。默认是不允许产生 c o r e core core 文件的，因为 c o r e core core 文件中可能包含用户密码等敏感信息，不安全。在开发调试阶段可以用 u l i m i t ulimit ulimit 命令改变这个限制，允许产生 c o r e core core 文件。 首先用 u l i m i t ulimit ulimit 命令改变 S h e l l Shell Shell 进程的 R e s o u r c e L i m i t Resource Limit ResourceLimit ，允许 c o r e core core 文件最大为 1024 K 1024K 1024K : $ `ulimit -c 1024`
> 在gdb中可以通过`core-file core文件` 命令来加载core文件，直接将定位到出错位置
> 
## 如何理解信号被进程保存：
> 表示信号有两点：
>
> 1. 什么信号
> 2. 是否产生
>
> 进程必须通过数据结构来保存信号（位图），也就是在进程PCB内部有信号位图字段
## 信号发送的本质：
> OS 向目标进程发送信号就是修改其信号位图
# 产生信号
## 1. 终端按键（组合键）变成信号：
```clike
ctrl + c # 终止进程
```
**如何理解终端按键（组合键）变成信号：**
> 键盘工作的方式是通过：中断方式进行的，能够识别每个按键，同样能识别组合键。
>
> OS解释组合键 ------\> 查看进程列表 ------\> 前台运行的进程 ------\> OS 写入对应信号到进程内部的位图结构中
## 2. 通过系统调用接口向进程发送信号
`kill`命令就是通过调用`kill`函数实现的
**如何理解系统调用产生信号：**
> 用户调用系统调用 ------\> 执行OS的系统调用代码 ------\> OS 提取参数 ------\> OS向目标进程写入信号 ------\> 修改对应进程的信号标志位 ------\> 进程处理信号 ------\> 执行对应的处理动作
## 3. 软件条件产生信号
* 管道读端关闭，写端一直写，写的进程会自动退出，就是因为OS向该进程发送了 `14) SIGPIPE` 信号。
* alarm函数
**如何理解软件条件产生信号：**
> OS先识别到某种软件条件触发或不满足 ------》 OS 构建信号，发送给指定信号
## 4. 硬件异常产生信号
1. 浮点数溢出错误
当程序中发生除0时，就会发生 `Floating point exception（浮点数溢出）` 错误，就是产生了`8) SIGFPE`信号。默认情况下会直接终止进程，如果通过`signal`自定义行为就会一直执行自定义的行为，为什么呢？
**如何理解除0**
> 进行计算的时CPU这个硬件，CPU内部是有寄存器的，对于计算状态有一个单独的状态寄存器（位图），发生了浮点数溢出错误溢出标志位就会被设为1，后面每次都会检测状态寄存器都会立即检测到溢出状态并向对应进程发送 8 号信号，但是状态寄存器里面溢出标志位不会被清空，所以该进程一直都是溢出状态，一直向进程发送 8 号信号
2. 野指针或越界错误
访问野指针或者越界会触发 `11) SIGSEGV` 信号，发生 `segment fault（段错误）`
**如何理解段错误：**
> 我们拿到的地址都是虚拟地址，访问目标地址时需要通过页表 + MMU（Memory Manage Unit，硬件）当转换成物理地址。如果时非法地址，MMU转换时会报错，也就是产生 11 号信号
## 总结
> **所有的信号都是由OS识别并发送的。**
# 信号阻塞
## 概念
* 实际执行信号的处理动作称为**信号递达(Delivery)**
* 信号从产生到递达之间的状态，称为**信号未决(Pending)**。
* 进程可以选择阻塞 (Block )某个信号。
* 被阻塞的信号产生时将保持在未决状态，直到进程解除对此信号的阻塞，才执行递达的动作.
* 注意：阻塞和忽略是不同的，只要信号被阻塞就不会递达，而忽略是在递达之后可选的一种处理动作。
## 在内核中的表示
* *SIG_DFL* 和 *SIG_IGN* 是宏，转换成指针函数的整数 0 和 1，进行信号递达前需要先将信号处理函数转换成整数，判断是忽略函数进行默认动作。
* `9) SIGKILL` 不会被阻塞
* 每个信号都有两个标志位分别表示阻塞(block)和未决(pending),还有一个函数指针表示处理动作。信号产生时，内核在进程控制块中设置该信号的未决标志，直到信号递达才清除该标志。在上图的例子中，*SIGHUP*信号未阻塞也未产生过，当它递达时执行默认处理动作。
* 信号产生没有递达会一直处于未决状态，如果信号阻塞，信号将一直处于未决状态。即便是忽略信号也是如此
* 常规信号在递达之前产生多次只计一次，而实时信号在递达之前产生多次可以依次放在一个队列里。
**例子：**
> * *SIGINT*信号产生过，但正在被阻塞，所以暂时不能递达。虽然它的处理动作是忽略，但在没有解除阻塞之前不能忽略这个信号，因为进程仍有机会改变处理动作之后再解除阻塞。
> * *SIGQUIT* 信号未产生过，一旦产生*SIGQUIT* 信号将被阻塞，它的处理动作是用户自定义函数`sighandler`。如果在进程解除对某信号的阻塞之前这种信号产生过多次，将如何处理？POSIX.1允许系统递送该信号一次或多次。Linux是这样实现的：常规信号在递达之前产生多次只计一次，而实时信号在递达之前产生多次可以依次放在一个队列里。
## sigset_t （信号集）
> 每个信号只有一个`bit`的未决标志，非0即1，不记录该信号产生了多少次，阻塞标志也是这样表示的。因此，未决和阻塞标志可以用相同的数据类型`sigset_t`来存储，`sigset_t`称为信号集，这个类型可以表示每个信号的"有效"或"无效"状态，在阻塞信号集中"有效"和"无效"的含义是该信号是否被阻塞，而在未决信号集中"有效"和"无效"的含义是该信号是否处于未决状态。下一节将详细介绍信号集的各种操作。 阻塞信号集也叫做当前进程的信号屏蔽字(Signal Mask)，这里的"屏蔽"应该理解为阻塞而不是忽略
## 信号集操作函数
用户只能通过特定的函数才能操作信号集：
```clike
#include