目录
一、可重入函数
（一）引入
我们来先看一个例子来帮助我们理解什么是可重入函数：
假设我们现在要对一个链表进行头插，在执行到第10行代码时，突然进程的时间片到了，进程被切换了，一会等进程再度切换回来时，当前进程要处理信号，而信号处理函数是sighandler，而sighandler里面也进行了头插，等进程从内核态返回到用户态时，继续执行第11行的代码，这时我们再观察链表的结构会发现链表中节点 node1 还未完成插入时，node2 也进行了头插，最终导致 节点 node2 丢失，造成 内存泄漏。
cpp
node_t node1, node2, *head;
int main()
{
...
insert(&node1);
...
}
void insert(node_t*p)
{
p->next = head;
head = p;
}
void sighandler(int signo)
{
insert(&node2);
}
导致 内存泄漏 的罪魁祸首：对于 node1 和 node2 来说，操作的 单链表 是同一个，同时进行并发访问（重入）会出现问题的 ，因为此时的单链表是 临界资源。
由这个问题衍生出了一种函数分类的方式：
- 如果一个函数同时被多个执行流进入所产生的结果没有问题 ，该函数被称为可重入函数。
- 如果一个函数同时被多个执行流进入所产生的结果有问题 ，该函数被称为不可重入函数。
- 可重入函数主要用于多任务环境中，一个可重入的函数通常来说就是可以被中断的函数，也就是说，可以在这个函数执行的任何时刻中断它，转入OS调度下去执行另外一段代码，而返回控制时不会出现什么错误；
- 不可重入的函数由于使用了一些系统资源，比如全局变量区，中断向量表等，所以它如果被中断的话，可能会出现问题，这类函数是不能运行在多任务环境下的。
（二）可重入函数的判断
如果一个函数符合以下条件之一则是不可重入的:
- 函数体内使用了静态（
static）的数据结构或者变量； - 调用了malloc或free,因为malloc也是用全局链表来管理堆的。
- 调用了标准I/O库函数 。标准I/O库的很多实现都以不可重入的方式使用全局数据结构。
二、volatile关键字
（一）概念
volatile是C语言的一个关键字，该关键字的作用是保证内存数据的可见性。
比如在下面这个例子中
借助全局变量 falg 设计一个死循环的场景，在此之前将 2 号信号进行自定义动作捕捉，具体动作为：将 flag 改为 1，可以终止 main 函数中的循环体
cpp
#include <stdio.h>
#include <signal.h>
int flag = 0; // 一开始为假
void handler(int signo)
{
printf("%d号信号已经成功发出了\n", signo);
flag = 1;
}
int main()
{
signal(2, handler);
while(!flag); // 故意不写 while 的代码块 { }
printf("进程已退出\n");
return 0;
}
初步结果符合预期，2 号信号发出后，循环结束，程序正常退出
这段代码能符合我们预期般的正确运行是因为 当前编译器默认的优化级别很低，没有出现意外情况。
通过指令查询 **gcc**优化级别的相关信息：
bash
man gcc
其中数字越大，优化级别越高，理论上编译出来的程序性能会更好。
事实真的如此吗？
让我们重新编译上面的程序，并指定优化级别为 O1
bash
gcc mySignal mySignal.c -O1
此时得到了不一样的结果：2 号信号发出后，对于 falg 变量的修改似乎失效了
将优化级别设为更高是一样的结果，如果设为 **O0**则会符合预期般的运行，说明我们当前的编译器默认的优化级别是 O0
查看编译器的版本：
bash
gcc --version
那么我们这段代码哪个地方被优化了呢？
- 答案是
while循环判断
首先要明白：
- 对于程序中的数据，需要先被
load到CPU中的 寄存器 中 - 判断语句所需要的数据（比如
flag），在进行判断时，是从 寄存器 中拿取并判断 - 根据判断的结果，判断代码的下一步该如何执行（通过
PC指针指向具体的代码执行语句）
所以程序在优化级别为 **O0**或更低时，是这样执行的：
（二）关于编译器的优化的简单讨论
上面的代码如果我们不开启优化，就算不加上volatile关键字也是能正常运行的，可见编译器的优化不是越高越好。
如何理解编译器的优化?
编译器的本质是将代码翻译成01的二进制序列，所以编译器的优化是在你编写的代码上动手脚，也就是说编译器的优化其实改变了一些最终翻译成01二进制以后的执行逻辑。
三、SIGCHLD信号
在 进程控制 学习时期，我们明白了一个事实：父进程必须等待子进程退出并回收，并为其 "收尸"，避免变成 "僵尸进程" 占用系统资源、造成内存泄漏。
那么 父进程是如何知道子进程退出了呢？
- 在之前的场景中，父进程要么就是设置为 阻塞式专心等待 ，要么就是 设置为
WNOHANG非阻塞式等待 ，这两种方法都需要 父进程 主动去检测 子进程 的状态。
如今学习了 进程信号 相关知识后，可以思考一下：子进程真的是安安静静的退出的吗？
- 答案当然不是，子进程在退出后，会给父进程发送
SIGCHLD信号。
可以通过 SIGCHLD 信号 通知 父进程，子进程 要退出了，这样可以解放 父进程 ，不必再去 主动检测 ，而是 子进程 要退出的时候才通知其来 "收尸"： 
SIGCHLD信号比较特殊，该信号的默认处理动作是忽略。
首先通过程序证明一下子进程会发出 **SIGCHLD**信号，通过自定义捕捉，打印相关信息：
cpp
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
void handler(int signo)
{
printf("进程 %d 捕捉到了 %d 号信号\n", getpid(), signo);
}
int main()
{
signal(SIGCHLD, handler);
pid_t id = fork();
if(id == 0)
{
int n = 5;
while(n)
printf("子进程剩余生存时间: %d秒 [pid: %d ppid: %d]\n", n--, getpid(), getppid());
// 子进程退出
exit(-1);
}
waitpid(id, NULL, 0);
return 0;
}
因此可以证明 SIGCHLD是被子进程真实发出的，当然，我们可以让父进程自定义捕捉动作为 回收子进程 ，让父进程不再主动检测子进程的状态，这样父进程只需专心处理自己的工作，不必关心子进程了，子进程终止时会通知父进程，父进程在信号处理函数中调用wait或waitpid清理子进程即可：
cpp
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
pid_t id; // 将子进程的id设为全局变量，方便对比
void handler(int signo)
{
printf("进程 %d 捕捉到了 %d 号信号\n", getpid(), signo);
// 这里的 -1 表示父进程等待时，只要是已经退出了的子进程，都可以进行回收
pid_t ret = waitpid(-1, NULL, 0);
if(ret > 0)
printf("父进程: %d 已经成功回收了 %d 号进程，之前的子进程是 %d\n", getpid(), ret, id);
}
int main()
{
signal(SIGCHLD, handler);
id = fork();
if(id == 0)
{
int n = 5;
while(n)
{
printf("子进程剩余生存时间: %d秒 [pid: %d ppid: %d]\n", n--, getpid(), getppid());
sleep(1);
}
// 子进程退出
exit(-1);
}
// 父进程很忙的话，可以去做自己的事
while(1)
{
// TODO
printf("父进程正在忙...\n");
sleep(1);
}
return 0;
}父进程和子进程各忙各的，子进程退出后会发信号通知父进程，并且能做到正确回收： 
那么这种方法就一定对吗？
- 答案是不一定，在只有一个子进程的场景中，这个代码没问题，但如果是涉及多个子进程回收时，这个代码就有问题了
根本原因：SIGCHLD 也是一个信号啊，它可能也会在 block 表和 pending 表中被置为 1，当多个子进程同时向父进程发出信号时，父进程只能先回收最快发出信号的子进程，并将随后发出信号的子进程 SIGCHLD 信号保存在 blcok 表中，除此之外，其他的子进程信号就丢失了，父进程处理完这两个信号后，就认为没有信号需要处理了，这就造成了内存泄漏。
解决方案：自定义捕捉函数中，采取 while 循环式回收，有很多进程都需要回收没问题，排好队一个个来就好了，这样就可以确保多个子进程同时发出 SIGCHLD 信号时，可以做到一一回收。
细节：多个子进程运行时，可能有的退了，有的没退，这会导致退了的子进程发出信号后，触发自定义捕捉函数中的循环等待机制，回收完已经退出了的子进程后，会阻塞式的等待还没有退出的子进程，如果子进程一直不退，就会一直被阻塞，所以我们需要把进程回收设为 WNOHANG 非阻塞式等待。
cpp
void handler(int signo)
{
printf("进程 %d 捕捉到了 %d 号信号\n", getpid(), signo);
// 这里的 -1 表示父进程等待时，只要是已经退出了的子进程，都可以进行回收
while (1)
{
pid_t ret = waitpid(-1, NULL, WNOHANG);
if (ret > 0)
printf("父进程: %d 已经成功回收了 %d 号进程\n", getpid(), ret);
else
break;
}
printf("子进程回收成功\n");
}
int main()
{
signal(SIGCHLD, handler);
// 创建10个子进程
int n = 10;
while (n--)
{
pid_t id = fork();
if (id == 0)
{
int n = 5;
while (n)
{
printf("子进程剩余生存时间: %d秒 [pid: %d ppid: %d]\n", n--, getpid(), getppid());
sleep(1);
}
// 子进程退出
exit(-1);
}
}
// 父进程很忙的话，可以去做自己的事
while (1)
{
// TODO
printf("父进程正在忙...\n");
sleep(1);
}
return 0;
}分为几批次地把所有子进程都成功回收了：
其实还有一种更加优雅的子进程回收方案：
由于 UNIX 历史原因，要想子进程不变成 僵尸进程 ，可以把 SIGCHLD的处理动作设为 SIG_IGN 忽略，这里的忽略是个特例，只是父进程不对其进行处理 ，但只要设置之后，子进程在退出时，由 操作系统 对其负责，自动清理资源并进行回收，不会产生 僵尸进程。
也就是说，直接在父进程中使用**signal(SIGCHLD, SIG_IGN)**就可以优雅的解决 子进程回收问题，父进程既不用等待，也不需要对信号做出处理。
原理：在设置 SIGCHLD 信号的处理动作为忽略后，父进程的 PCB 中有关僵尸进程处理的标记位会被修改，子进程继承父进程的特性，子进程在退出时，操作系统检测到此标记位发生了改变，会直接把该子进程进行释放。
SIGCHLD的默认处理动作是忽略（什么都不做），而忽略动作是让操作系统帮忙回收，父进程不必关心
注意： 这种情况很特殊，只能保证在 Linux 系统中有效，其他类 UNIX 系统中可能没啥用。