Linux 进程信号深剖

传统艺能

小编是双非本科大二菜鸟不赘述，欢迎米娜桑来指点江山哦

1319365055

非科班转码社区诚邀您入驻
小伙伴们，满怀希望，所向披靡，打码一路向北
一个人的单打独斗不如一群人的砥砺前行
这是和梦想合伙人组建的社区，诚邀各位有志之士的加入！！
社区用户好文均加精（“标兵”文章字数2000+加精，“达人”文章字数1500+加精）
直达： 社区链接点我

---

概念

信号是一个生活中随处可见的概念，没什么深层隐晦的地方，一个信号包含了各种信息，比如你快递到了，你该吃饭了或者你该睡觉了等等

首先在 Linux 系统中，我们首先需要$明白信号的产生是异步的$，比如有以下代码：

#include 
#include 

int main()
{
	while (1){
		printf("hello signal!\n");
		sleep(1);
	}
	return 0;
}

运行结果是死循环，我们要终止死循环的话通常会直接 ctrl c：

这里的 ctrl c 动作就是一个信号，本质上是因为输入产生了一个硬中断，ctrl c 被翻译成 2 号信号送到操作系统，操作系统再送到前台进程，然后前台进程退出。

这里所谓的 2 号信号我们可以听过 signal 函数进行捕捉，声明为：

#include 
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);

signum：要捕捉的信号编号 　
handler：捕捉信号的处理方法，处理方法的参数是 int，返回值是 void

这里就以对 ctrl c 的捕捉为例：

可以看到这里系统确实收到另一个 2 号信号！

信号是进程之间事件异步通知的一种方式，属于$软中断$

ctrl c 产生的信号只能发给前台进程，在命令后面加 & 就可以放到后台运行，这样 Shell 不必等待进程结束就可以接收新命令，启动新的进程。当然 Shell 可以同时运行一个前台进程和任意多个后台进程，但是只有前台进程才能接到像 ctrl c 这种控制信号

该进程的用户空间代码执行到任何地方都可能收到 SIGINT信号（ctrl c 对应的 2 号信号）而终止，所以信号相对于进程的控制流程来说是异步的。

信号发送

我们可以通过 kill -l 命令查看 Linux 中所有的信号：

其中1-31号信号是普通信号，34-64号信号是实时信号，普通信号和实时信号各自都有31个，每个信号都有一个编号和一个宏定义名称：

信号记录

实际上进程接收一个信号，该信号是被记录在该进程的进程控制块当中的。我们都知道进程控制块本质上就是一个结构体变量，我们主要就是记录一个信号是否产生，因此我们可以用一个 32 位的位图来记录信号是否产生

其中比特位的位置代表信号的编号，而比特位的内容就代表是否收到对应信号，比如第 6 个比特位是 1 就表明收到了 6 号信号

信号产生

首先我们要知道信号是如何产生的

收到信号的本质就是进程内的信号位图被修改，也就是进程的数据被修改，而只有操作系统才有资格修改进程的数据，因为操作系统是进程的管理者。也就是说，信号的产生本质上就是操作系统直接去修改目标进程的 task_struct 中的信号位图。

常见信号处理方式

对于一个信号我们有三种处理方式：

1. 执行该信号的默认处理动作
2. 提供一个信号处理函数，要求内核在处理该信号时切换到用户态执行这个处理函数，这种方式称为捕捉一个信号
3. 直接忽略信号

Linux 我们可以使用 man 指令来查看处理方式：

man 7 signal

终端按键产生信号

最开始我们对于死循环程序输入 ctrl c 进行终止的动作就是通过终端按键产生信号，但是其实除了 ctrl c 以外，ctrl \ 也可以终止程序：

那么问题来了， ctrl c 和 ctrl \ 的区别在哪里？

ctrl c 实际上是发送 2 号信号SIGINT，而 ctrl \ 实际上是发送3号信号SIGQUIT。查看这两个信号的默认处理动作，可以看到这两个信号的 Action 是不一样的，2 号信号是 Term，而 3 号信号是 Core

Term 和 Core 都代表终止进程，但是 Core 在终止进程时会进行$核心转储$

核心转储

嘛是核心转储？其实可以理解为运行时报错日志，我们知道在一个代码运行结束后如果有报错，我们可以通过退出码得知错误信息，但是如果是一个运行的代码错误，我们只能通过核心转储获悉错误原因

在运行中如果崩溃了，我们一般会直接进行 debug 调试，但是有些特殊情况下我们会用到核心转储，核心转储的本质是一个$磁盘文件$，也叫核心转储文件，它是操作系统在进程收到信号而终止后，会将进程地址空间的内容，状态和其他信息转而存储到磁盘中，一般命名为core.pid

我们我们通过 ulimit -a 指令查看当前资源限制设定，这里我们看到在云服务器里面，核心转储功能是默认关闭的，因为 core 文件大小为 0：

我们可以自己通过 ulimit -c 来改变 core 文件的大小：

这里有了 core 文件就证明核心转储功能已经被我们开发♂出来了，再次使用 ctrl \ 就会出现 core dump 信息（因为我的服务器搞了汉化包，这里的硬核翻译比较尴尬，吐核就是 core dump）：

且在当前目录下会产生一个 core+一串数字后缀的文件，这一串数字其实就是这次核心转储的进程的 PID：

ulimit 指令改变的是 shell 的 Resource Limit，这里 signal 的 PCB 也是由 shell 复制来的，所以 signal 也具有和 shell 相同的 Resource Limit

如何调试

我们下面这个简单的除0场景为例：

崩溃后就会出现报错信息:

接下来查看 core dump 文件：

在进入 gdb 调试模式，使用core-file + core文件名命令加载core文件，即可判断出该程序在终止时收到了8号信号，并且定位到了产生该错误的具体代码：

8 号信号对应的就是算术错误。

core dump 标识在讲 waitpid 时就有说过：

pid_t waitpid(pid_t pid, int *status, int options);

waitpid 的第二个参数 status 是一个输出型参数，他用于获取子进程的退出状态，他是一个整型参数，但是我们不能单纯将它看成一个整数，因为他的不同比特位有不同的含义：

我们只关注 status 的 16 位，如果进程时正常退出，次低 8 位就会记录退出状态，也就是我们说的退出码，如果是因为信号异常退出，低 8 位的第一位就是 core dump，记录了核心转储：

我们此时就可以开启系统的核心转储功能，编写一个代码实现父进程 fork 子进程，并在子进程里面进行野指针的实现，在 *p = 100 执行时，系统会终止并且会立即进行核心转储，我们在 waitpid 后查看对应的终止信号：

#include 
#include 
#include 
#include 
#include 

int main()
{
	if (fork() == 0){
		//child
		printf("I am running...\n");
		int *p = NULL;
		*p = 100;
		exit(0);
	}
	//father
	int status = 0;
	waitpid(-1, &status, 0);
	printf("exitCode:%d, coreDump:%d, signal:%d\n",
		(status >> 8) & 0xff, (status >> 7) & 1, status & 0x7f);
	return 0;
}

效果如下：

因此 core dump 标志就是表示当前进程是否进行了核心转储！

那么还有其他组合键操作吗？我们可以通过代码捕捉所有信号，并将收到信号的默认动作改为直接打印出该信号的编号：

#include 
#include 
#include 

void handler(int signal)
{
	printf("get a signal:%d\n", signal);
}
int main()
{
	int signo;
	for (signo = 1; signo <= 31; signo++){
		signal(signo, handler);
	}
	while (1){
		sleep(1);
	}
	return 0;
}

此时我们执行 9 号信号系统不会打印出编号而是直接执行他的默认动作，这就说明操作系统里面并不是所有的信号都可以被捕获，因为如果全部可以捕获且可以设置为忽略，那么操作系统将无法杀死这个进程即使是操作系统！

系统函数发送信号

当我们使用 kill 命令向一个进程发送信号时，我们可以以kill -信号名 进程ID 或者 kill -信号编号 进程ID 的形式进行发送：

实际上 kill 命令是通过调用 kill 函数实现的，函数的函数原型如下：

int kill(pid_t pid, int sig);

函数用于向进程 ID 为 pid 的进程发送 sig 信号，信号发送成功返回 0 ，不然返回 -1。这里可以用 kill 函数模拟实现一个 kill 命令：

#include 
#include 
#include 
#include 

void Usage(char* proc)
{
	printf("Usage: %s pid signo\n", proc);
}
int main(int argc, char* argv[])
{
	if (argc != 3){
		Usage(argv[0]);
		return 1;
	}
	pid_t pid = atoi(argv[1]);
	int signo = atoi(argv[2]);
	kill(pid, signo);
	return 0;
}

为了让程序在每次执行时可以不带上路径，可以将当前路径导入环境变量 PATH 当中，我们通过 export 函数实现：

效果如下：

raise函数

raise 可以给当前进程发送指定信号，即自己给自己发送信号，raise 的函数原型：

int raise(int sig);

raise 的信号发送成功则返回 0，否则返回一个非零值。例如，下面用 raise 每隔一秒向自己发送一个 2 号信号：

#include 
#include 
#include 

void handler(int signo)
{
	printf("get a signal:%d\n", signo);
}
int main()
{
	signal(2, handler);
	while (1){
		sleep(1);
		raise(2);
	}
	return 0;
}

效果如下：

abort函数

abort 可以给当前进程发送 SIGABRT 信号，使进程异常终止，abort 的函数原型如下：

void abort(void);

例如下面代码每隔一秒向当前进程发送一个 SIGABRT 信号：

#include 
#include 
#include 
#include 

void handler(int signo)
{
	printf("get a signal:%d\n", signo);
}
int main()
{
	signal(6, handler);
	while (1){
		sleep(1);
		abort();
	}
	return 0;
}

结果如下：

这里虽然对 SIGABRT 信号进行了捕捉，并且执行了我们给出的自定义方法，但进程还是异常终止了。

由软件条件产生信号

SIGPIPE信号

SIGPIPE 信号实际上就是一种由软件条件产生的信号，当进程在使用管道进行通信时，关闭读端，而写端在一直向管道写入数据，那么此时写端进程就会收到 SIGPIPE 信号进而被操作系统终止。

下面代码创建匿名管道进行父子进程之间的通信，让父进程作为读端进程，子进程是写端进程，但是一开始通信父进程就将读端关闭了，那么此时子进程在向管道写入数据时就会收到 SIGPIPE 信号而被终止

#include 
#include 
#include 
#include 
#include 
#include 
int main()
{
	int fd[2] = { 0 };
	if (pipe(fd) < 0){ //pipe()创建匿名管道
		perror("pipe");
		return 1;
	}
	pid_t id = fork(); 
	if (id == 0){
		//child
		close(fd[0]); //子进程关闭读端
		const char* msg = "hello father, I am child...";
		int count = 10;
		while (count--){
			write(fd[1], msg, strlen(msg));
			sleep(1);
		}
		close(fd[1]); //子进程写入完毕
		exit(0);
	}
	//father
	close(fd[1]); //父进程关闭写端
	close(fd[0]); //再关闭读端导致子进程被操作系统杀掉
	int status = 0;
	waitpid(id, &status, 0);
	printf("child get signal:%d\n", status & 0x7F); 
	return 0;
}

子进程在退出时收到的是13号信号，即SIGPIPE信号：

SIGALRM信号

alarm 函数可以设定一个闹钟，也就是告诉操作系统在若干时间后发送SIGALRM信号给当前进程，函数原型如下：

unsigned int alarm(unsigned int seconds);

$作用$：操作系统在seconds秒之后给当前进程发送SIGALRM信号，SIGALRM信号的默认处理动作是终止进程

调用 alarm 前进程已经设置了闹钟，则返回上一个闹钟的剩余时间，并且本次闹钟的设置会覆盖上一次。如果没有设置闹钟，则返回值为 0。

例如用下面代码测试云服务器一秒时间内可以将一个变量累加到多大：

#include 
#include 
#include 

int main()
{
	int count = 0;
	alarm(1);
	while (1){
		count++;
		printf("count: %d\n", count);
	}
	return 0;
}

效果如下，可以发现我的云服务器可以将一个变量累加到两万左右：

其实云服务器可以打印到远超 2 万的结果，但是由于每次都进行打印操作，与外设之间的IO操作所需时间比累加时间更长，其次，由于当前使用的是云服务器，因此还需要将累加结果通过网络传输将数据发送过来，因此最终显示的结果要比实际一秒内可累加次数小得多

所以我们可以先让 count 变量一直执行累加操作，直到一秒后进程收到SIGALRM信号后再打印累加后的数据：

#include 
#include 
#include 
#include 

int count = 0;
void handler(int signo)
{
	printf("get a signal: %d\n", signo);
	printf("count: %d\n", count);
	exit(1);
}
int main()
{
	signal(SIGALRM, handler);
	alarm(1);
	while (1){
		count++;
	}
	return 0;
}

结果如下，结果明显变成了 5 亿多，相比原来结果可以看出实际的 IO 是十分消耗时间的：

MMU

说到硬件异常不得不抛出一个问题：$为什么C++程序会崩溃？$

当程序当中出现类似于除0、野指针、越界之类的错误时程序就会崩溃。本质上是因为进程在运行过程中收到了操作系统发来的信号进而被终止，那操作系统是如何识别到一个进程触发了某种问题的呢？

我们知道，CPU有一堆的寄存器，当我们需要进行算术运算时，会先将这两个操作数分别放到两个寄存器当中，计算完后将结果写回寄存器当中。此外，CPU当中还有一组寄存器叫做状态寄存器，它可以用来标记当前结果的状态信息，如有无进位、有无溢出等等。而操作系统是软硬件资源的管理者，在程序运行过程中，若操作系统因为出现了除 0 错误而导致了某个状态位发生了置位，那么此时操作系统就会马上识别到是哪个进程导致的该错误，并将所识别到的硬件错误包装成信号发送给目标进程，本质就是操作系统去直接找到这个进程的task_struct，并向该进程的位图中写入8信号，写入8号信号后这个进程就会在合适的时候被终止。

那对于野指针或者越界访问问题时，操作系统又如何识别呢？

首先我们要知道系统要访问一个变量时，首先需要建立一张页表，将虚拟地址映射成物理地址才能进行访问，这里页表就是一种软件映射关系，而此时完成映射工作还有一个硬件参与工作，那就是 $MMU$，他负责处理 CPU 的内存访问请求，虽然目前 MMU 已经集成到了 CPU 里面，但是完成映射的工作是 MMU 完成而不是 CPU

当进行虚拟地址到物理地址的映射时，会先将页表左侧的虚拟地址导给 MMU，然后 MMU 会计算出物理地址，我们再通过这个地址进行访问。

而 MMU 既然是硬件单元，那么它当然也有状态信息，当我们要访问不属于我们的虚拟地址时，MMU 在进行虚拟地址到物理地址的转换时就会出现错误，然后将对应的错误写入到自己的状态信息中，这时硬件上的信息也会立马被操作系统识别，进而将对应进程发送SIGSEGV信号

所以程序崩溃最终一定会在硬件上有所表现，操作系统识别后就会发生相应信号去终止进程

阻塞信号

1. 实际执行信号的处理动作，称为信号递达（Delivery）
2. 信号从产生到递达之间的状态，称为信号未决（pending）
3. 进程可以选择阻塞（Block）某个信号。

被阻塞的信号产生时将保持在未决状态，直到进程解除对此信号的阻塞，才执行递达的动作。但是阻塞和忽略是不同的，只要信号被阻塞就不会递达，而忽略是在递达之后才能忽略。

信号的内核表示

信号的内核表示如图：

每个信号都有两个标志位分别表示阻塞 block 和未决 pending，还有一个函数指针表示处理动作。信号产生时，内核在进程控制块中设置该信号的未决标志，直到信号递达才清除该标志，比如上图中，SIGHUP信号未阻塞也未产生过，当它递达时执行默认处理动作

SIGINT信号产生过，但正在被阻塞，所以暂时不能递达。虽然它的处理动作是忽略，但在没有解除阻塞之前不能忽略这个信号，因为进程仍有机会在改变处理动作之后再接触阻塞。

SIGQUIT信号未产生过，但一旦产生 SIGQUIT 信号，该信号将被阻塞，它的处理动作是用户自定义函数 sighandler。如果在进程解除对某信号的阻塞之前，这种信号产生过多次，POSIX.1 允许系统递达该信号一次或多次。Linux 是这样实现的：普通信号在递达之前产生多次只计一次，而实时信号在递达之前产生多次可以依次放在一个队列里，这里我们讨论普通信号

总结

1. block、pending 和 handler 这三张表的每一个位置是一一对应的
2. 在block 位图中，比特位的位置代表某一个信号，比特位的内容代表该信号是否被阻塞
3. 在pending 位图中，比特位的位置代表某一个信号，比特位的内容代表是否收到该信号
4. handler 表本质上是一个函数指针数组，数组的下标代表某一个信号，数组的内容代表该信号递达时的处理动作，处理动作包括默认、忽略以及自定义

sigset_t

根据信号在内核中的表示方法，每个信号的未决标志只有一个比特位非 0 即 1，如果不记录该信号产生次数，那么阻塞标志也只有一个比特位

因此，未决和阻塞标志可以用相同的数据类型 sigset_t 来存储，sigset_t 称为$信号集$，这个类型可以表示每个信号的“有效”或“无效”状态。

sigset_t 定义如下（不同操作系统实现 sigset_t 方案可能不同）：

#define _SIGSET_NWORDS (1024 / (8 * sizeof (unsigned long int)))
typedef struct
{
	unsigned long int __val[_SIGSET_NWORDS];
} __sigset_t;

typedef __sigset_t sigset_t;

注意阻塞信号集也叫做当前进程的信号屏蔽字，这里的屏蔽应该理解为阻塞而不是忽略！

信号集操作函数

sigset_t 类型内部如何存储这些比特位会依赖于系统的实现，从使用者的角度是不必关心的，使用者只能调用以下函数来操作 sigset_t 变量，比如用 printf 直接打印 sigset_t 变量是没有意义的

#include 

int sigemptyset(sigset_t *set);

int sigfillset(sigset_t *set);

int sigaddset(sigset_t *set, int signum);

int sigdelset(sigset_t *set, int signum);

int sigismember(const sigset_t *set, int signum);  

sigemptyset函数：初始化set所指向的信号集，使其中所有信号的对应 bit 清零
sigfillset函数：初始化set所指向的信号集，使其中所有信号的对应bit置位，表示该信号集的有效信号包括系统支持的所有信号
sigaddset函数：在set所指向的信号集中添加某种有效信号
sigdelset函数：在set所指向的信号集中删除某种有效信号 sigemptyset、sigfillset、sigaddset和sigdelset函数都是成功返回0，出错返回-1
sigismember函数：判断在set所指向的信号集中是否包含某种信号，若包含则返回1，不包含则返回0，调用失败返回-1

在使用sigset_t类型的变量之前，一定要调用sigemptyset或sigfillset做初始化，使信号处于确定的状态。例如：

#include 
#include 

int main()
{
	sigset_t s; //用户空间定义的变量

	sigemptyset(&s);

	sigfillset(&s);

	sigaddset(&s, SIGINT);

	sigdelset(&s, SIGINT);

	sigismember(&s, SIGINT);
	return 0;
}

代码中的sigset_t类型的变量 s，与我们平常定义的变量一样都是在用户空间定义的变量，所以后面信号集操作函数对 s 的操作实际上是对用户空间的变量 s 做了修改，并不影响进程的任何行为。因此，我们还需要通过系统调用，才能将变量 s 的数据设置进操作系统

sigprocmask

sigprocmask 可以用于读取或更改进程的信号屏蔽字（阻塞信号集），函数函数原型如下：

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

如果 oldset 是非空指针，则读取进程当前的信号屏蔽字通过 oldset 参数传出。如果 set 是非空指针，则更改进程的信号屏蔽字，参数 how 代表如何更改

如果 oldset 和 set 都是非空指针，则先将原来的信号屏蔽字备份到 oldset 里，然后根据 set 和 how 更改信号屏蔽字

参数 how 有如下可选值：

函数调用成功返回0，出错返回-1，注意如果 sigprocmask 解除了对当前若干个未决信号的阻塞，则在 sigprocmask 函数返回前，至少将其中一个信号递达

sigpending

sigpending 可用于读取进程的未决信号集，函数原型如下：

int sigpending(sigset_t *set);

函数读取当前进程的未决信号集，并通过set参数传出。该函数调用成功返回0，出错返回 -1

我们不妨来实验一下：用上述的函数将 2 号信号进行屏蔽阻塞，再使用 kill 命令或组合按键向进程发送 2 号信号。此时2号信号会一直被阻塞，并一直处于 pending 状态，这时使用 sigpending 获取当前进程的 pending 信号集进行验证

#include 
#include 
#include 

void printPending(sigset_t *pending)
{
	int i = 1;
	for (i = 1; i <= 31; i++){
		if (sigismember(pending, i)){
			printf("1 ");
		}
		else{
			printf("0 ");
		}
	}
	printf("\n");
}
int main()
{
	sigset_t set, oset;
	sigemptyset(&set);
	sigemptyset(&oset);

	sigaddset(&set, 2); //SIGINT
	sigprocmask(SIG_SETMASK, &set, &oset); //阻塞2号信号
	sigset_t pending;
	sigemptyset(&pending);

	while (1){
		sigpending(&pending); //获取 pending
		printPending(&pending); //打印位图，1 即表示未决
		sleep(1);
	}
	return 0;
}

效果如下：

使用 kill 向该进程发送 2 号信号后，由于2号信号是阻塞的，因此2号信号一直处于未决状态，所以我们看到pending表中的第二个数字一直是 1

为了看到 2 号信号递达后 pending 表的变化，可以设置一段时间后自动解除 2 号信号的阻塞状态，解除后就会立即递达。因为 2 号信号的默认处理动作是终止进程，所以为了看到 2 号信号递达后的 pending 表，我们可以将 2 号信号进行捕捉，让 2 号信号递达时执行我们所给的自定义动作：

#include 
#include 
#include 

void printPending(sigset_t *pending)
{
	int i = 1;
	for (i = 1; i <= 31; i++){
		if (sigismember(pending, i)){
			printf("1 ");
		}
		else{
			printf("0 ");
		}
	}
	printf("\n");
}
void handler(int signo)
{
	printf("handler signo:%d\n", signo);
}
int main()
{
	signal(2, handler);
	sigset_t set, oset;
	sigemptyset(&set);
	sigemptyset(&oset);

	sigaddset(&set, 2); //SIGINT
	sigprocmask(SIG_SETMASK, &set, &oset); //阻塞2号信号

	sigset_t pending;
	sigemptyset(&pending);

	int count = 0;
	while (1){
		sigpending(&pending); //获取pending
		printPending(&pending); //打印位图，1 表示未决
		sleep(1);
		count++;
		if (count == 20){
			sigprocmask(SIG_SETMASK, &oset, NULL); //恢复曾经的信号屏蔽字
			printf("恢复信号屏蔽字\n");
		}
	}
	return 0;
}

效果如下：

进程收到 2 号信号后，信号在一段时间内处于未决状态，当解除 2 号信号的屏蔽后，2 号信号就会立即递达，执行我们所给的自定义动作，而此时的 pending 表又变回了全 0

捕捉信号

每一个进程都有自己的进程地址空间，这个空间又由两部分组成：$内核空间和用户空间$

1. 用户所写的代码和数据位于用户空间，通过用户级页表与物理内存之间建立映射关系。
2. 内核空间存储的实际上是操作系统代码和数据，通过内核级页表与物理内存之间建立映射关系

内核级页表是一个全局的页表，它用来维护操作系统的代码与进程之间的关系。因此，用户空间是属于当前进程的，每个进程看到的代码和数据是完全不同的，但内核空间所存放的都是操作系统的代码和数据，所有进程看到的都是一样的内容:

当然，虽然每个进程都能够看到操作系统，但并不意味着每个进程都能够随时对其进行访问。

之前那说的切换进程的本质就是在当前进程的内核空间里面找到操作系统的代码和数据，再执行操作系统代码，将当前进程的代码剥离并换上新的代码和数据

访问用户空间时就必须处于用户态，访问内核空间时必须处于内核态。

内核态与用户态

1. 内核态通常用来执行操作系统的代码，是一种高权限状态
2. 用户态是一种用来执行普通用户代码的状态，是一种受监管的普通状态

进程收到信号之后，并不是立即处理信号，而是在从内核态切换回用户态的时候

从用户态切换为内核态通常有如下几种情况：

1. 需要进行系统调用时
2. 当前进程的时间片到了，导致进程切换
3. 产生异常、中断、陷阱等

从内核态切换为用户态有如下几种情况：
4. 系统调用返回时
5. 进程切换完毕
6. 异常、中断、陷阱等处理完毕

用户态切换为内核态又称为陷入内核。每当我们需要陷入内核的时，本质上是因为我们需要执行操作系统的代码，比如系统调用函数是由操作系统实现的，我们要进行系统调用就必须先由用户态切换为内核态

信号捕捉的实现

当进程在用户态执行时会因为一些原因陷入内核，这时在返回用户时会先检查 pending 状态，因为此时还在内核，所以仍有权限查看 pending 表，检查 pending 时如果发现有未决信号且没有被阻塞，就会对这个信号进行处理。

信号的默认动作是忽略或者默认，此时执行完 pending 后就会清除 pending 标志位，如果没有新的信号递达，就会返回用户态然后从主进程中断的地方继续进行：

如果这个信号是自义定捕捉的，因为是用户自义定的自义定捕捉动作，进程会先从内核返回用户态进行自义定动作处理，然后使用特殊系统调用 sigreturn 再次陷入内核，在清除对应的 pending 标志位后，如果没有新的信号递达，就会返回用户态继续执行：

注意sighandler和main函数使用不同的堆栈空间，它们之间没有相互调用的关系，是两个独立的控制流程！我们可以简化记忆上面的自义定捕捉：

那么问题来了，如果识别到当前进程执行自义定动作时，可以直接在内核空间执行吗？

理论上内核的高权限是绝对支持的，但是实际上是绝对不可以只有设计的，因为内核的高权限是没有可控性的，如果存在非法代码就寄了，用户态是没办法直接执行清空数据库的，但是内核态是可以的。因为操作系统不能确定用户代码的合法性，因此操作系统不相信任何用户

sigaction

捕捉信号除了用 signal 函数之外，我们还可以使用 sigaction 函数捕捉信号，函数原型如下：

int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);

sigaction 函数可以读取和修改与指定信号相关联的处理动作，函数调用成功返回 0，出错返回 -1

signum：指定信号的编号
若 act 指针非空，则根据 act 修改该信号的处理动作
若 oldact 指针非空，则通过 oldact 传出该信号原来的处理动作

其中 act 和 oldact 都是指针类型结构体变量，定义如下：

struct sigaction {
	void(*sa_handler)(int);
	void(*sa_sigaction)(int, siginfo_t *, void *);
	sigset_t   sa_mask;
	int        sa_flags;
	void(*sa_restorer)(void);
};

sa_handler

sa_handler 赋值为SIG_IGN传给 sigaction 函数，表示忽略信号
sa_handler 赋值为SIG_DFL传给 sigaction 函数，表示执行默认动作
sa_handler赋值为一个函数指针，表示用自定义函数捕捉信号，或者说向内核注册了一个信号处理函数

所注册的信号处理函数的返回值为 void，参数为 int，通过参数可以得知当前信号的编号，这样就可以用同一个函数处理多种信号。显然这是一个回调函数，不是被 main 函数调用，而是被系统所调用

sa_sigaction

sa_sigaction 是实时信号的处理函数

sa_mask

首先需要说明的是，当某个信号的处理函数被调用，内核自动将当前信号加入进程的信号屏蔽字，当信号处理函数返回时自动恢复原来的信号屏蔽字，这样就保证了在处理某个信号时，如果这种信号再次产生，那么它会被阻塞到当前处理结束为止。

如果在调用信号处理函数时，除了当前信号被自动屏蔽之外，还希望自动屏蔽另外一些信号，则用 sa_mask 说明需要额外屏蔽的信号，当信号处理函数返回时，再恢复原来的信号屏蔽字

sa_flags

这里直接将 sa_flags 设置为0即可

sa_restorer

该参数没有使用。我们用 sigaction 函数对 2 号信号进行了捕捉，将2号信号的处理动作改为了自定义的打印动作，并在执行一次自定义动作后将 2 号信号的处理动作恢复为原来默认的处理动作：

#include 
#include 
#include 
#include 

struct sigaction act, oact;
void handler(int signo)
{
	printf("get a signal:%d\n", signo);
	sigaction(2, &oact, NULL);
}
int main()
{
	memset(&act, 0, sizeof(act));
	memset(&oact, 0, sizeof(oact));

	act.sa_handler = handler;
	act.sa_flags = 0;
	sigemptyset(&act.sa_mask);

	sigaction(2, &act, &oact);
	while (1){
		printf("I am a process...\n");
		sleep(1);
	}
	return 0;
}

效果如下，第一次向进程发送2号信号，执行我们自定义的打印动作，当我们再次向进程发送2号信号，就执行该信号的默认处理动作了，即终止进程：

可重入函数

先来看一个场景，如果有一个 insert 函数支持链表的插入，在主函数中调用异常插入 node1，在信号处理函数中调用一次插入 node2，这里理论上是没有问题的：

大致就是这个链表：

首先 main 函数中调用 insert，insert 分为两步，在第一步执行完后会因为硬件中断陷入内核，再次回到用户态就会检查十分有待处理的信号，于是跳转到了 sighandler 函数：

此时 sighandler 也调用了 insert 函数，继续执行：

完成插入后会从 sighandler 函数返回内核态，返回后的布局如下:

再次回到用户态时会从 main 函数原来的地方继续向下执行，布局如下：

最后就是 main 函数和 sighandler 函数先后向链表中插入了两个结点，但最后只有 node1 结点真正插入到了链表中，而 node2 结点直接寄了，造成了内存泄漏

各函数执行顺序如下：

insert 函数被不同的控制流调用，这里 main 函数和 sighandler 函数使用不同的堆栈空间，它们之间相互调用关系，是两个独立的控制流程，有可能在第一次调用还没返回时就再次进入该函数，我们将这种现象称之为$重入$。

而 insert 函数访问一个全局链表，有可能因为重入而造成错乱，像这样的函数我们称之为$不可重入函数$，反之如果一个函数只访问自己的局部变量或参数，则称之为$重入$

如果一个函数符合以下条件之一则是不可重入的：

1. 调用了 malloc 或 free，因为 malloc 也是用全局链表来管理堆的
2. 调用了标准 I/O 库函数，因为标准 I/O 库很多实现都以不可重入的方式使用全局数据结构

volatile

该关键字的作用是保持内存的可见性

我们对 2 号信号进行了捕捉，当该进程收到 2 号信号时会将全局变量 flag 由 0 置 1。也就是说在进程收到 2 号信号之前，该进程会一直处于死循环状态，直到收到 2 号信号时将 flag 置1才能够正常退出:

#include 
#include 

int flag = 0;

void handler(int signo)
{
	printf("get a signal:%d\n", signo);
	flag = 1;
}
int main()
{
	signal(2, handler);
	while (!flag);
	printf("Proc Normal Quit!\n");
	return 0;
}

效果如下：

该程序的运行过程好像都在我们的意料之中，但实际并非如此。代码中的 main 函数和 handler 函数是两个独立的执行流，而 while 循环是在 main 函数当中的，编译时只能检测在 main 函数中对 flag 变量的使用

但 main 函数中并没有对 flag 变量做修改操作，在编译器优化级别较高的时候，就有可能将 flag 设置进寄存器里面，此时 main 函数只检测寄存器里面的值，而 handler 执行流只是将内存中的 flag 置为 1 了，那么就算收到 2 号信号也不会跳出死循环！

编译时加上-O3选项使编译器的优化级别最高，此时再运行代码该进程就不会终止：

此时即可以使用volatile关键字对 flag 变量进行修饰，告诉编译器对 flag 变量的任何操作都必须真实的在内存中进行，即保持了内存的可见性

#include 
#include 

volatile int flag = 0;
…………

效果如图：

SIGCHILD

为了避免僵尸进程的出现，父进程会使用 wait 或 waitpid 等待子进程结束，而等待方式分为阻塞等待和非阻塞等待，阻塞即父进程必须停止运行等待子进程，非阻塞就是采用轮询方式，具体实现复杂，二者都没有尽善尽美

其实子进程在终止时会给父进程发生SIGCHLD信号，默认处理动作是忽略，父进程可以自定义SIGCHLD信号的处理动作，这样父进程就可以专心工作了，子进程终止时通知父进程，最后父进程调用 wait 或 waitpid 清理子进程即可！

过程表示为：

#include 
#include 
#include 
#include 
#include 

void handler(int signo)
{
	printf("get a signal: %d\n", signo);
	int ret = 0;
	while ((ret = waitpid(-1, NULL, WNOHANG)) > 0){
		printf("wait child %d success\n", ret);
	}
}
int main()
{
	signal(SIGCHLD, handler);
	if (fork() == 0){
		//child
		printf("child is running, begin dead: %d\n", getpid());
		sleep(3);
		exit(1);
	}
	//father
	while (1);
	return 0;
}

效果如下：

UNIX 下还提出另外一种办法：父进程调用 signal 或 sigaction 函数将 SIGCHLD 信号的处理动作设置为SIG_IGN，这样 fork 的子进程在终止时会自动清理掉，不会产生僵尸进程也不会通知父进程。但这是一个特列。此方法对于 Linux 可用，但不保证在其他 UNIX 系统上都可用！

aqa 芭蕾 eqe 亏内，代表着开心代表着快乐，ok 了家人们