标签：max   硬编码   href   知识点   不能   异常   读写   order   printf   

　　关于linux信号的知识点，我找到一篇博客写的非常好：https://www.cnblogs.com/hoys/archive/2012/08/19/2646377.html

　　本篇博客主要是为了加深自己的理解，并且在上篇博客的基础上做一些扩充，有可能会有说的不对的地方。

　　具体与信号相关的资料可以用输入man 3 signal命令查看。

1、概述

　　信号其实和硬件中的中断非常类似，硬件中断有很多种类型，比如串口中断、定时器中断、I2C中断等，每个不同的中断会有对应的中断处理函数，在中断处理函数里面就会处理引起中断的事件。linux中的信号就相当于这些中断，因此不同的信号代表发生了不同的事件。但是它们的区别其实还是挺大的，比如信号是发送给某一进程的，而不是整个系统。

2、信号种类

　　在终端输入kill -l命令可以看到linux支持的所有信号类型，如下：

 　　从这个列表中能看出下列几点：

　　1. 所有的名称都是以SIG开头的；

　　2. 每个信号名称前面有1个数字，用半边括号包围；

　　3. 没有32和33号信号。

　　4. 34号信号名为SIGRTMIN，接下来的15个信号分别为SIGRTMIN+1~SIGRTMIN+15，64号信号名为SIGRTMAX，它之前的14个信号分别为SIGRTMAX-14~SIGRTMAX-1；

　　下面解释一下上述问题，SIG是signal前3个字母，后面的部分是具体的信号简称，比如第14个信号SIGALRM其实就是signal alarm（闹钟信号），这个就有点像硬件中的RTC中断。每个信号名其实就是一个宏（常量），这在signal.h中定义了（不是include目录下的signal.h，而是include目录下的某个目录下的signal.h，具体是哪个目录视平台而定。但奇怪的是signal.h中明明定义的SIGRTMIN的值为32，但是我打印出来却是34，不过和kill -l列出来的SIGRTMIN也是34）。

　　信号的命名和值和历史原因有关，这个在man手册上写了，在不同的标准中加入了不同的信号，基本上每个信号都有对应的事件，但是这些信号个问题，就是不支持排队，也就是说如果同时出现好几个信号，那么只有1个信号能处理，其他的信号会丢失。如果修改这个机制的话，可能会导致天下大乱，然后大神们就想出一种办法，增加了信号的类型，新增的信号类型与旧的信号类型有所区别，那就是新增的信号类型支持排队，它们即使同时来好几个也不会丢失，那么顺理成章的，旧的信号就成了不可靠信号，新的信号就是可靠信号（在手册中的说法是普通信号和实时信号，只不过按照我的理解我更倾向于叫它们不可靠信号和可靠信号）。

　　但是新增的这些信号并没有对应任何一个实际的事件，它们根据实际情况来使用（手册上是这么写的），因此就不好给它们取名字了，索性就把新增的这些信号划分到一个范围里，最小的值叫做SIGRTMIN，最大的值叫SIGRTMAX，其中RT就是Real-Time，然后用SIGRTMIN+n和SIGRTMAX-n的方法来表示它们。

　　需要注意的是，虽然定义了SIGRTMIN和SIGRTMAX的值，但是在使用的时候还是应该要用SIGRTMIN+n和SIGRTMAX-n的方式，原因如下：

　　The Linux kernel supports a range of 32 different real-time signals, numbered 33 to 64. However, the glibc POSIX threads implementation internally uses two (for NPTL) or three (for LinuxThreads) real-time signals (see pthreads(7)), and adjusts the value of SIGRTMIN suitably (to 34 or 35). Because the range of available real-time signals varies according to the glibc threading implementation (and this variation can occur at run time according to the available kernel and glibc), and indeed the range of real-time signals varies across UNIX systems, programs should never refer to real-time signals using hard-coded numbers, but instead should always refer to real-time signals using the notation SIGRTMIN+n, and include suitable (run-time) checks that SIGRTMIN+n does not exceed SIGRTMAX.

　　翻译如下：

　　Linux内核支持32种不同的实时信号，范围从33到64。但是，glibc POSIX线程实现内部使用两个（对于NPTL）或三个（对于LinuxThreads）实时信号（请参阅pthreads（7））。 ，并适当调整SIGRTMIN的值（至34或35）。 因为可用的实时信号的范围根据glibc线程实现的不同而有所不同（并且这种变化可能会在运行时根据可用的内核和glibc发生），并且实际上，实时信号的范围在UNIX系统上也有所不同，所以程序应 不要使用硬编码数字引用实时信号，而应该使用SIGRTMIN + n引用实时信号，并包括适当的（运行时）检查，以确保SIGRTMIN + n不超过SIGRTMAX。

 　　虽然实时信号没有对应具体的事件，但是普通信号有对应具体的事件，而且系统还给每个普通信号设定了一个默认的处理方法，下表列出了信号名，信号值，系统对该信号的默认处理动作和产生该信号的原因：

　　注：上表中很多暂停和停止其实是一个意思，因为这些东西都是从英语翻译过来的，原文就是stopped，直译应该为“停止”，但按照中文的习惯，停止代表不能恢复，能恢复就应该叫“暂停”。

　　Core dump：当程序运行的过程中异常终止或崩溃，操作系统会将程序当时的内存状态记录下来，保存在一个文件中，这种行为就叫做Core Dump（中文有的翻译成“核心转储”)。我们可以认为 core dump 是“内存快照”，但实际上，除了内存信息之外，还有些关键的程序运行状态也会同时 dump 下来，例如寄存器信息（包括程序指针、栈指针等）、内存管理信息、其他处理器和操作系统状态和信息。core dump 对于编程人员诊断和调试程序是非常有帮助的，因为对于有些程序错误是很难重现的，例如指针异常，而 core dump 文件可以再现程序出错时的情景。参见：https://www.cnblogs.com/s-lisheng/p/11278193.html

　　从上表可以看出系统对信号默认的处理方法一共有5种，分别是：1. 终止；2. 终止，并进行Core dump；3. 暂停运行；4. 继续运行；5. 忽略。

3、 普通信号捕捉

　　虽然表中所有的信号都有默认的处理方法，但我们可以来捕捉这些信号，并修改处理方法，需要用到的函数为signal函数，该函数介绍如下：

　　该函数的原型比较难理解，可以将之拆分为两部分：void (*signal(int sig, void (*func)(int)))(int); 其中黑色部分是返回值，红色部分是其余部分，将红色部分拿出来：signal(int sig, void (*func)(int)) 发现这是一个含有2个参数的函数，第一个参数是整形的，第2个参数是void (*)(int)类型的函数指针，第2个参数的函数指针类型与返回值的函数指针类型是相同的。如果用自定义的函数来处理信号，当信号到来时就会调用传入的函数指针，而给该函数传入的参数正是信号类型。最后捋一捋，signal这个函数包含2个参数，第一个是int型的，表示信号类型，第2个是void (*)(int)型的函数指针，用来定义对第1个参数指定的信号的处理函数，它的返回值也是void (*)(int)型的函数指针，当signal调用成功时返回的函数指针是上一次处理该信号的函数指针（也包含SIG_IGN和SIG_DFL）。

　　写一个简单的程序来测试一下signal的用法，选用的信号为SIGINT，通过组合键Ctrl+C发送，代码如下：

 1 /**
 2  * filename: signal_2.c
 3  * author: Suzkfly
 4  * date: 2021-02-15
 5  * platform: Ubuntu
 6  *     操作步骤：
 7  *     修改MODE的值为1,2,3，执行程序时按下Ctrl+C，观察结果。
 8  */
 9 #include <stdio.h>
10 #include <fcntl.h>
11 #include <sys/types.h>
12 #include <sys/stat.h>
13 #include <signal.h>
14 
15 #define MODE 3
16 
17 /* 自定义信号处理函数 */
18 void func(int sig)
19 {
20     if (sig == SIGINT) {
21         printf("SIGINT signal captured\n");
22     }
23 }
24 
25 int main(int argc, const char *argv[])
26 {
27     int fd = 0;
28     void (*p)(int); /* 定义一个函数指针 */
29 
30     printf("MODE = %d\n", MODE);
31 #if (MODE == 1)     /* 忽略 */
32     printf("SIG_IGN = %p\n", SIG_IGN);
33     p = signal(SIGINT, SIG_IGN);
34     printf("p = %p\n", p);
35     p = signal(SIGINT, SIG_IGN);
36     printf("p = %p\n", p);
37 #elif (MODE == 2)   /* 默认 */
38     printf("SIG_DFL = %p\n", SIG_DFL);
39     p = signal(SIGINT, SIG_DFL);
40     printf("p = %p\n", p);
41     p = signal(SIGINT, SIG_DFL);
42     printf("p = %p\n", p);
43 #elif (MODE == 3)   /* 自定义 */
44     printf("func = %p\n", func);
45     p = signal(SIGINT, func);
46     printf("p = %p\n", p);
47     p = signal(SIGINT, func);
48     printf("p = %p\n", p);
49 #endif
50     
51     while (1) {
52         sleep(5);
53         printf("running...\n");
54     }
55     
56     return 0;
57 }

测试结果：

修改代码中MODE的值以达到不同的测试结果，3种不同的结果如下图：

说明：

1. 屏幕上出现的“^C”字样表示按下了Ctrl+C，屏幕上的“^\Quit”字样表示按下了Ctrl+\

2. MODE等于3时的Ctrl+C是持续按下的（间隔远小于5秒）

 结果分析：

这份代码用于验证signal函数和SIGINT信号，通过这份代码验证了下列特性：

1. signal函数能够修改信号的处理方式；

2. SIG_IGN的值其实就是1，SIG_DFL的值其实就是0；

3. signal函数如果成功，那么返回的是上一次的处理函数，也包含SIG_IGN和SIG_DFL；

4. SIGINT信号的默认处理方式是终止进程；

5. SIGINT信号能够唤醒进程。

进程间通信之——信号（一）

标签：max   硬编码   href   知识点   不能   异常   读写   order   printf   

原文地址：https://www.cnblogs.com/Suzkfly/p/14401421.html