Linux——信号（2）

在上一张博客我们介绍了Linux中信号的概念和信号是如何产生的，虽然信号
有多种产生方式，但是最终只能由操作系统给对应进程发送特定信号。现在
我将更加规范的介绍Linux中的信号。

上一章的遗留问题

我们上一章中在观察信号的默认处理的时候发现终止信号的种类可以分为两种，Term和Core：

我们可以发现Core类信号产生的异常错误的严重程度是要高于Term类型的。而且出现了Core类错误时，我们在修复错误时往往是需要修改代码本身的。所以Core类型的信号在被处理时，同时也会生成一个文件，这个文件的文件名包含Core和出现异常的进程pid，这个文件保存了进程出异常时，进程中的一些重要的数据：
如果是使用虚拟机的小伙伴可能会观察到这种文件。但是使用云服务器的小伙伴可能并没有见过这种文件，我们可以使用ulimit -a查看系统的一些配置的大小，在云服务器上：

可以看到云服务器上这个文件的大小被设置成了0，那也就是相当于不生成这种文件。而在虚拟机中这个文件的大小不一定是被设置成了0。我们可以使用ulimit -c来修改这个文件配置的大小：

我们设置好文件配置的大小之后我们写一段代码：

我们再重新起一个shell然后再运行这个程序，再本来这个shell上也运行一遍：
新的shell进程上：

可见它并没有生成什么包含core和进程pid的文件。
本来的shell进程上：

它生成了这样的一个文件，那为什么新起的shell进程上没有生成呢？我们发现在新起的shell进程上：

它的大小仍旧是0，至此我们可以得出使用ulimit -c修改的配置文件的大小，它的作用效果是随shell进程的。
那么这个文件有什么用呢？我们打开它可以看到它就是二进制：

我们说了，它其中会记录进程中的一些重要的数据。这使得我们可以使用gdb来便捷的定位到哪句代码出了问题：

这种技术叫做核心转储。
那么为什么云服务器会将它的大小设置为0不让它生成呢？我们可以看到，这个文件是比较大的，假如我们多生成几个呢？

这还只是一行代码，如果是公司企业中的服务器代码呢？我们都知道服务器中的服务上线之后，会有运维人员来保证服务器中服务的正常运行，而现在也有自动化运维，它可以在进程异常退出之后，可以重新让这个服务跑起来，那么此时此刻对于我们现在这个代码，它每一次启动都会带来那么大的文件，我们的代码可能一秒就启动上千次，那么这样的话，我们的磁盘用不了多久就被写满了，这对我们要修复异常的服务就更加的困难了，磁盘满了之后我们一般是对这台机器做不了任何操作了。

1. 一些规范的名词

信号递达：实际执行信号的处理动作
信号未决：信号从产生到递达之间的状态
阻塞：处于信号未决和信号递达之间的状态，其实也是一直处于信号未决状态，直到信号
被停止阻塞，然后才会递达

信号递达其实就是处理信号，普通信号的信号是不会叠加的，它产生多少次也只算一次，递达前后未决状态就会被取消，无论之前有多少次信号未决，这也跟位图本身的特性有关。
而信号未决其实就是信号的产生也就是task_struct结构体中的信号位图被写入
我们以前介绍过，对于信号的处理方式有三种：默认处理，忽略，自定义捕捉。其中我们要清楚忽略它本身也是对于信号的处理方式（例如老师布置了作业之后，你选择视而不见这本身也是对这件事情的一个处理方式，你听到了老师布置作业叫做信号未决，你写作业就叫做信号递达。你对老师布置作业这条消息视而不见忽略也叫做信号递达，因为你处理了这个信号）。
有些人会将忽略和阻塞混淆成一个东西这是不对的，阻塞是只要信号只要被阻塞后就不会被递达，而忽略是这个信号已经递达了。两者截然不同。
在前面我介绍了信号的自定义捕捉使用signal接口，这里我介绍信号的默认处理以及忽略，它们是由两个宏实现的：
信号默认处理：


在这段代码中我们开始将二号信号设置成自定义捕捉，在信号递达时将进行我们自定义的函数，会打印出如上结果，但是当cnt–到小于0时我们将2号信号更改为默认处理，此时我们ctrl + c就会直接退出进程，其中SIG_DFL就是将信号设置成默认处理方式的宏。
忽略处理：


SIG_IGN是将信号忽略的宏，可以看到当我们使用ctrl + c的组合键终止进程的时候并没有任何反应，使用ctrl + \才终止了进程。
观察这两个宏的定义其实它们就是强转而已：