CSAPP 异常控制流
每次从一条指令过渡到另外一条指令的过程称为控制转移，这样的一个控制转移序列叫做控制流，如果每条指令都是相邻的，这样的过渡就是平滑序列。如果一条指令与另外一条指令不相邻，这样突发性的过渡称为异常。从进程切换、用户态与内核态的转换到系统实时响应各种事件，都离不开异常这个概念。
异常控制流
从开机到关机，处理器做的工作其实很简单，就是不断读取并执行指令，每次执行一条，整个指令执行的序列，称为处理器的控制流。到目前为止，我们已经学过了两种改变控制流的方式：
- 跳转和分支
- 调用和返回
这两个操作对应于程序的改变。但是这实际上仅仅局限于程序本身的控制，没有办法去应对更加复杂的情况。系统状态发生变化的时候，无论是跳转/分支还是调用/返回都是无能为力的，比如：
- 数据从磁盘或者网络适配器到达
- 指令除以了零
- 用户按下 ctrl+c
- 系统的计时器到时间
这时候就要轮到另一种更加复杂的机制登场了，称之为异常控制流(exceptional control flow)。首先需要注意的是，虽然名称里包含异常（实际上也用到了异常），但是跟代码中 try catch 所涉及的异常是不一样的。通常try catch被叫做应用级ECF,我们这里论述的异常是包含这个应用级ECF的。
异常控制流存在于系统的每个层级，最底层的机制称为异常(Exception)，用以改变控制流以响应系统事件，通常是由硬件的操作系统共同实现的。更高层次的异常控制流包括进程切换(Process Context Switch)、信号(Signal)和非本地跳转(Nonlocal Jumps)，也可以看做是一个从硬件过渡到操作系统，再从操作系统过渡到语言库的过程。进程切换是由硬件计时器和操作系统共同实现的，而信号则只是操作系统层面的概念了，到了非本地跳转就已经是在 C 运行时库中实现的了。
接下来我们就分别来看看这四个跨域计算机不同层级的异常控制流机制。
异常 Exception
这里的异常指的是把控制交给系统内核来响应某些事件（例如处理器状态的变化），其中内核是操作系统常驻内存的一部分，而这类事件包括除以零、数学运算溢出、页错误、I/O 请求完成或用户按下了 ctrl+c 等等系统级别的事件。
系统为可能出现的每种类型的异常分配了唯一的异常号，发生对应异常时会通过异常号跳转到对应的异常处理程序处。所有的异常号被系统初始化成一张异常表的跳转表，起始地址被存放在异常表基寄存器（exception table base register）中。
异常类型
异常分为四种：
| 类型 | 原因 | 行为 | 异步/同步 | 示例 |
|---|---|---|---|---|
| 陷阱 | 有意的异常 | 返回到下一条指令 | 同步 | 系统调用，断点 |
| 故障 | 潜在可恢复的错误 | 返回到当前指令 | 同步 | 页故障(page faults) |
| 终止 | 不可恢复的错误 | 终止当前程序 | 同步 | 非法指令 |
| 中断 | 来自VO设备的信号 | 总是返回到下一条指令 | 异步 | I/O设备发送信号 |
异步异常（中断)是由处理器外面发生的事情引起的,所以CPU并不知道何时可以对其操作，对其的响应也完全是被动的。对此采取了两种方式来获取这个异常（中断):
- 计时器中断:由计时器芯片每隔几毫秒触发的，内核用计时器终端来从用户程序手上拿回控制权
- I/O 中断:I/O 中断类型比较多样，比方说键盘输入了 ctrl-c，网络中一个包接收完毕，都会触发这样的中断。
同步异常(Synchronous Exception)是因为执行某条指令所导致的事件，我们把这类指令叫做故障指令（faulting instruction）。
系统调用示例
系统调用看起来像是函数调用，但其实是走异常控制流的，在 x86-64 系统中，每个系统调用都有一个唯一的 ID，比如常见的read,write编号分别是0,1，而fork编号是57。
系统调用对应示意图：
故障示例
以 Page Fault 为例，来说明 Fault 的机制。Page Fault 发生的条件是：
- 用户写入内存位置
- 但该位置目前还不在内存中
比如：
int a[1000];
main()
{
a[500] = 13;
}
那么系统会通过 Page Fault 把对应的部分载入到内存中，然后重新执行赋值语句：
但是如果代码改为这样：
int a[1000];
main()
{
a[5000] = 13;
}
也就是引用非法地址的时候，整个流程就会变成：
具体来说会像用户进程发送 SIGSEGV 信号，用户进程会以 segmentation fault 的标记退出。
从上面我们就可以看到异常的具体实现是依靠在用户代码和内核代码间切换而实现的，是非常底层的机制。
进程
进程是计算机科学中最为重要的思想之一，进程是程序（指令和数据）的正在运行的实例。之所以重要，是因为进程给每个应用提供了两个非常关键的抽象：一是逻辑控制流，二是私有地址空间。逻辑控制流通过称为上下文切换(context switching)的内核机制让每个程序都感觉自己在独占处理器。私有地址空间则是通过称为虚拟内存(virtual memory)的机制让每个程序都感觉自己在独占内存。这样的抽象使得具体的进程不需要操心处理器和内存的相关适宜，也保证了在不同情况下运行同样的程序能得到相同的结果。
进程切换 Process Context Switch
这么多进程，具体是如何工作的呢？我们来看看下面的示意图：
左边是单进程的模型，内存中保存着进程所需的各种信息，因为该进程独占 CPU，所以并不需要保存寄存器值。而在右边的单核多进程模型中，虚线部分可以认为是当前正在执行的进程，因为我们可能会切换到其他进程，所以内存中需要另一块区域来保存当前的寄存器值，以便下次执行的时候进行恢复（也就是所谓的上下文切换）。整个过程中，CPU 交替执行不同的进程，虚拟内存系统会负责管理地址空间，而没有执行的进程的寄存器值会被保存在内存中。切换到另一个进程的时候，会载入已保存的对应于将要执行的进程的寄存器值。
而现代处理器一般有多个核心，所以可以真正同时执行多个进程。这些进程会共享主存以及一部分缓存，具体的调度是由内核控制的，示意图如下：
切换进程时，内核会负责具体的调度，如下图所示
进程控制 Process Control
系统调用错误的处理
在遇到错误的时候，Linux 系统级函数通常会返回 -1 并且设置 errno 这个全局变量来表示错误的原因。使用的时候记住两个规则：
- 对于每个系统调用都应该检查返回值
- 当然有一些系统调用的返回值为 void，在这里就不适用
例如，对于 fork() 函数，我们应该这么写：
if ((pid = fork()) < 0) {
fprintf(stderr, "fork error: %s\n", strerror(errno));
exit(0);
}
如果觉得这样写太麻烦，可以利用一个辅助函数：
void unix_error(char *msg) /* Unix-style error */
{
fprintf(stderr, "%s: %s\n", msg, strerror(errno));
exit(0);
}
// 上面的片段可以写为
if ((pid = fork()) < 0)
unix_error("fork error");
C语言为我们提供了一个更简便的包装函数，自带错误处理：
pid_t Fork(void)
{
pid_t pid;
if ((pid = fork()) < 0)
unix_error("Fork error");
return pid;
}
获取进程信息
我们可以用下面两个函数获取进程的相关信息：
- pid_t getpid(void) - 返回当前进程的 PID
- pid_t getppid(void) - 返回当前进程的父进程的 PID
我们可以认为，进程有三个主要状态
- 运行 Running
- 正在被执行、正在等待执行或者最终将会被执行
- 停止 Stopped
- 执行被挂起，在进一步通知前不会计划执行
- 终止 Terminated
- 进程被永久停止
另外的两个状态称为新建(new)和就绪(ready)，与java层面的线程状态对比图：
终止进程
在下面三种情况时，进程会被终止：
- 接收到一个终止信号
- 返回到 main
- 调用了 exit 函数
创建进程
调用 fork 来创造新进程。这个函数很有趣，执行一次，但是会返回两次，子进程几乎和父进程一模一样，会有相同且独立的虚拟地址空间，也会得到父进程已经打开的文件描述符(file descriptor)。比较明显的不同之处就是进程 PID 了。
有以下几点需要注意：
- 调用一次，但是会有两个返回值
- 并行执行，不能预计父进程和子进程的执行顺序
- 拥有自己独立的地址空间（也就是变量都是独立的），除此之外其他都相同
- 在父进程和子进程中 stdout 是一样的（都会发送到标准输出）
加载并运行程序
如果想在子进程载入其他的程序，就需要使用 execve 函数，execve函数加载并运行可执行目标文件filename（将程序作为一个进程加载进内存），且带参数列表argv和环境变量列表envp。只有当出现错误时，例如不能发现filename，execve才会返回到调用程序。所以，不像fork会一次调用返回两次，execve调用一次并从不返回。
进程图
进程图是一个很好的帮助我们理解进程执行的工具：
- 每个节点代表一条执行的语句
- a -> b 表示 a 在 b 前面执行
- 边可以用当前变量的值来标记
- printf 节点可以用输出来进行标记
- 每个图由一个入度为 0 的节点作为起始
对于进程图来说，只要满足拓扑排序，就是可能的输出。
int main()
{
pid_t pid;
int x = 1;
pid = Fork();
if (pid == 0)
{ // Child
printf("child! x = %d\n", --x);
exit(0);
}
// Parent
printf("parent! x = %d\n", x);
exit(0);
}
对应的进程图为
回收子进程
即使主进程已经终止，子进程也还在消耗系统资源，我们称之为『僵尸』。为了『打僵尸』，就可以采用『收割』(Reaping) 的方法。父进程利用 wait 或 waitpid 回收已终止的子进程，然后给系统提供相关信息，kernel 就会把 zombie child process 给删除。
如果父进程不回收子进程的话，通常来说会被 init 进程(pid == 1)回收，所以一般不必显式回收。但是在长期运行的进程中，就需要显式回收（例如 shell 和 server）。
信号 Signal
Linux 的进程树，可以通过 pstree 命令查看，如下图所示：
对于前台进程来说，我们可以在其执行完成后进行回收，而对于后台进程来说，因为不能确定具体执行完成的时间，所以终止之后就成为了僵尸进程，无法被回收并因此造成内存泄露。
这怎么办呢？同样可以利用异常控制流，当后台进程完成时，内核会中断常规执行并通知我们，具体的通知机制就是『信号』(signal)。
信号是 Unix、类 Unix 以及其他 POSIX 兼容的操作系统中进程间通讯的一种有限制的方式。它是一种异步的通知机制，用来提醒进程一个事件已经发生。当一个信号发送给一个进程，操作系统中断了进程正常的控制流程，此时，任何非原子操作都将被中断。如果进程定义了信号的处理函数，那么它将被执行，否则就执行默认的处理函数。
信号允许一个进程中断其他进程。这样看来，信号其实是类似于异常和中断的，是由内核（在其他进程的请求下）向当前进程发出的。信号的类型由 1-30 的整数定义，信号所能携带的信息极少，一是对应的编号，二就是信号到达这个事实。下面是几个比较常用的信号的编号及简介：
| 编号 | 名称 | 默认动作 | 对应事件 |
|---|---|---|---|
| 2 | SIGINT | 终止 | 用户输入 ctrl+c |
| 9 | SIGKILL | 终止 | 终止程序（不能重写或忽略） |
| 11 | SIGSEGV | 终止且 Dump | 段冲突 Segmentation violation |
| 14 | SIGALRM | 终止 | 时间信号 |
| 17 | SIGCHLD | 忽略 | 子进程停止或终止 |
内核通过给目标进程发送信号，来更新目标进程的状态，具体的场景为：
- 内核检测到了如除以零(SIGFPE)或子进程终止(SIGCHLD)的系统事件
- 另一个进程调用了 kill 指令来请求内核发送信号给指定的进程
目标进程接收到信号后，内核会强制要求进程对于信号做出响应，可以有几种不同的操作：
- 忽略这个型号
- 终止进程
- 捕获信号，执行信号处理器(signal handler)，类似于异步中断中的异常处理器(exception handler)
具体的过程如下：
如果信号已被发送但是未被接收，那么处于等待状态(pending)，同类型的信号至多只会有一个待处理信号(pending signal)，一定要注意这个特性，因为内部实现机制不可能提供较复杂的数据结构，所以信号的接收并不是一个队列。比如说进程有一个 SIGCHLD 信号处于等待状态，那么之后进来的 SIGCHLD 信号都会被直接扔掉。
当然，进程也可以阻塞特定信号的接收，但信号的发送并不受控制，所以被阻塞的信号仍然可以被发送，不过直到进程取消阻塞该信号之后才会被接收。内核用等待(pending)位向量和阻塞(blocked)位向量来维护每个进程的信号相关状态。
进程组
每个进程都只属于一个进程组，从前面的进程树状图中我们也能大概了解一二，想要了解相关信息，一般使用如下函数：
- getpgrp() - 返回当前进程的进程组
- setpgid() - 设置一个进程的进程组
我们可以据此指定一个进程组或者一个单独的进程，比方说可以通过 kill 应用来发送信号，例如：
# 创建子进程
linux> ./forks 16
Child1: pid=24818 pgrp=24817
Child2: pid=24819 pgrp=24817
# 查看进程
linux> ps
PID TTY TIME CMD
24788 pts/2 00:00:00 tcsh
24818 pts/2 00:00:02 forks
24819 pts/2 00:00:02 forks
24820 pts/2 00:00:00 ps
# 可以选择关闭某个进程
linux> /bin/kill -9 24818
# 也可以关闭某个进程组，会关闭该组中所有进程
linux> /bin/kill -9 -24817
# 查看进程
linux> ps
PID TTY TIME CMD
24788 pts/2 00:00:00 tcsh
24820 pts/2 00:00:00 ps
这里可以看到，第一个命令只会杀掉编号为 24818 的进程，但是第二个命令，因为有两个进程都属于进程组 24817，所以会杀掉进程组中的每个进程。
这里kill -9,数字的意思就是前面说的信号编号，编号9对应SIGKILL，即exit。exit信号不会被系统阻塞。
而一般不带数字的kill命令，默认编号15，即发送一个SIGTERM信号给对应的程序，这样会阻塞直到软件退出。
我们也可以通过键盘让内核向每个前台进程发送 SIGINT(SIGTSTP) 信号
- SIGINT - ctrl+c 默认终止进程
- SIGTSTP - ctrl+z 默认挂起进程
下面是一个简单的例子
linux> ./forks 17
Child: pid=28108 pgrp=28107
Parent: pid=28107 pgrp=28107
# 按下 ctrl+z
Suspended # 进程被挂起
linux> ps w
PID TTY STAT TIME COMMAND
27699 pts/8 Ss 00:00 -tcsh
28107 pts/8 T 00:02 ./forks 17
28108 pts/8 T 00:02 ./forks 17
28109 pts/8 R+ 00:00 ps w
linux> fg
./forks 17
# 按下 ctrl+c，进程被终止
linux> ps w
PID TTY STAT TIME COMMAND
27699 pts/8 Ss 00:00 -tcsh
28109 pts/8 R+ 00:00 ps w
STAT 部分的第一个字母的意思
- S: 睡眠 sleeping
- T: 停止 stopped
- R: 运行 running
第二个字母的意思：
- s: 会话管理者 session leader
- +: 前台进程组
更多信息可以查看 man ps
接收信号
所有的上下文切换都是通过调用某个异常处理器(exception handler)完成的，当内核从一个异常处理程序返回，准备将控制传递给进程p时，它会检查未被阻塞的待处理信号的集合（pending&blocked）。
- 如果集合为空，那么就把控制交给进程 p 的逻辑流中的下一条指令
- 如果非空，内核会在集合内选择一个信号k(通常是最小的那位),并强制进程p接收这个信号k，最后把控制交给进程 p 的逻辑流中的下一条指令。
每个信号类型都有一个预定义的『默认动作』（前面的信号表格描述了信号的默认动作），可能是以下的情况：
- 终止进程
- 终止进程并 dump core
- 停止进程，收到 SIGCONT 信号之后重启
- 忽略信号
进程可以通过使用signal函数修改和信号相关联的默认动作。函数原型为 handler_t *signal(int signum, handler_t *handler)。我们通过一个简单的例子来感受下，这里我们屏蔽了 SIGINT 函数，即使按下 ctrl+c 也不会终止
void sigint_handler(int sig) // SIGINT 处理器
{
printf("想通过 ctrl+c 来关闭我？\n");
sleep(2);
fflush(stdout);
sleep(1);
printf("OK. :-)\n");
exit(0);
}
int main()
{
// 设定 SIGINT 处理器
if (signal(SIGINT, sigint_handler) == SIG_ERR)
unix_error("signal error");
// 等待接收信号
pause();
return 0;
}
动作的修改在于选择不同的handler：
- 如果handler是SIG_IGN，那么忽略类型为signum的信号。
- 如果handler是SIG_DFL，那么类型为signum的信号行为恢复为默认行为。
- 否则，就进入处理信号处理程序（signal handler）处理类型为signum的信号
惟一的例外是SIGSTOP和SIGKILL，它们的默认行为是不能修改的。
信号处理器的工作流程可以认为是和当前用户进程『并发』的同一个『伪』进程，值得注意的是，信号处理器也可以被其他的信号处理器中断，控制流如下图所示：
我们知道，内核会阻塞与当前在处理的信号同类型的其他正待等待的信号，也就是说，一个 SIGINT 信号处理器是不能被另一个 SIGINT 信号中断的。
如果想要显式阻塞，就需要使用 sigprocmask 函数了，以及其他一些辅助函数：
- sigemptyset - 创建空集
- sigfillset - 把所有的信号都添加到集合中（因为信号数目不多）
- sigaddset - 添加指定信号到集合中
- sigdelset - 删除集合中的指定信号
我们可以用下面这段代码来临时阻塞特定的信号：
sigset_t mask, prev_mask;
Sigemptyset(&mask); // 创建空集
Sigaddset(&mask, SIGINT); // 把 SIGINT 信号加入屏蔽列表中
// 阻塞对应信号，并保存之前的集合作为备份
Sigprocmask(SIG_BLOCK, &mask, &prev_mask);
...
... // 这部分代码不会被 SIGINT 中断
...
// 取消阻塞信号，恢复原来的状态
Sigprocmask(SIG_SETMASK, &prev_mask, NULL);
安全处理信号
信号处理器的设计并不简单，因为它们和主程序并行且共享相同的全局数据结构，尤其要注意因为并行访问可能导致的数据损坏的问题，这里提供一些基本的指南（后面的课程会详细介绍）
- 规则 1：信号处理器越简单越好
- 例如：设置一个全局的标记，并返回
- 规则 2：信号处理器中只调用异步且信号安全(async-signal-safe)的函数
- 诸如 printf, sprintf, malloc 和 exit 都是不安全的！
- 规则 3：在进入和退出的时候保存和恢复 errno
- 这样信号处理器就不会覆盖原有的 errno 值
- 规则 4：临时阻塞所有的信号以保证对于共享数据结构的访问
- 防止可能出现的数据损坏
- 规则 5：用 volatile 关键字声明全局变量
- 这样编译器就不会把它们保存在寄存器中，保证一致性
- 规则 6：用 volatile sig_atomic_t 来声明全局标识符(flag)
- 这样可以防止出现访问异常
Posix 标准指定了 117 个异步信号安全(async-signal-safe)的函数（可以通过 man 7 signal 查看）
非本地跳转 Non local Jump
所谓的本地跳转，指的是在一个程序中通过 goto 语句进行流程跳转，尽管不推荐使用goto语句，但在嵌入式系统中为了提高程序的效率，goto语句还是可以使用的。本地跳转的限制在于，我们不能从一个函数跳转到另一个函数中（非正常调用函数）。如果想突破函数的限制，就要使用 setjmp 或 longjmp 来进行非本地跳转了。
setjmp 保存当前程序的堆栈上下文环境(stack context)，注意，这个保存的堆栈上下文环境仅在调用 setjmp 的函数内有效，如果调用 setjmp 的函数返回了，这个保存的堆栈上下文环境就失效了。调用 setjmp 的直接返回值为 0。
longjmp 将会恢复由 setjmp 保存的程序堆栈上下文，即程序从调用 setjmp 处重新开始执行，不过此时的 setjmp 的返回值将是由 longjmp 指定的值。注意longjmp 不能指定0为返回值，即使指定了 0，longjmp 也会使 setjmp 返回 1。
我们可以利用这种方式，来跳转到其他的栈帧中，比方说在嵌套函数中，我们可以利用这个快速返回栈底的函数，我们来看如下代码
jmp_buf env;
P1()
{
if (setjmp(env))
{
// 跳转到这里
} else
{
P2();
}
}
P2()
{
...
P2();
...
P3();
}
P3()
{
longjmp(env, 1);
}
对应的跳转过程为：
也就是说，我们直接从 P3 跳转回了 P1，但是也有限制，函数必须在栈中（也就是还没完成）才可以进行跳转，下面的例子中，因为 P2 已经返回，所以不能跳转了
jmp_buf env;
P1()
{
P2(); P3();
}
P2()
{
if (setjmp(env))
{
// 跳转到这里
}
}
P3()
{
longjmp(env, 1);
}
因为 P2 在跳转的时候已经返回，对应的栈帧在内存中已经被清理，所以 P3 中的 longjmp 并不能实现期望的操作
总结
这一章主要讲了操作系统中最重要的概念，进程。而再深入底层，异常控制流是进程最基本的实现方式。4种异常：中断、故障、终止、和陷阱。信号又是进程中最重要的，简单却强大的信使。结合信号和进程，因为系统进程并行的缘故，具体编写程序的时候有许多需要注意的地方。