第四种，软件也可以产生信号：

比如说之前的管道，读端关闭，写端也会关闭，然后导致这个软件触发条件，发生信号。

在Linux下有一个叫定时器的软件，可以设定一个闹钟，如果时间到了，会给当前进程发送编号为14的信号。（闹钟只会响一次）

参数是按照秒为单位设置一个信号。

#include <iostream>
#include <unistd.h>
#include <signal.h>
#include <sys/types.h>
#include <cstdlib>
using namespace std;
int main(int argc, char *argv[])
{
    int count = 0;
    alarm(1);
    while(true)
    {
      count++;
        cout << count << endl;
    }
    return 0;
}

这段代码的功能是统计1S左右能让我们的计算机数据累加多少次。

其实正常来说CPU不会这么慢，可以改进一下代码：

#include <iostream>
#include <unistd.h>
#include <signal.h>
#include <sys/types.h>
#include <cstdlib>
using namespace std;
int count = 0;
void catchSig(int sig)
{
    cout << count <<endl;
    exit(1);
}
int main()
{
    signal(14, catchSig);
    alarm(1);
    while(true)
    {
        count++;
    }
    return 0;
}

那么为什么差距这么大呢？

因为打印是一种外设输出，访问外设的时候是很慢的，需要大量的时间，第一段代码一直在通过外设进行打印，所以很慢，第二段之后结束的时候才会通过外设打印。

如果是服务器还要经过网络IO，会更慢。

”闹钟“其实就是用软件实现的：

任何一个进程都可以通过alarm系统调用在内核中设计闹钟，OS内可能会存在很多的闹钟，OS也一定要管理这些闹钟，先描述再组织。

用struct alarm类型的对象去描述各个进程的闹钟数据：

struct alarm
{
  uint64_t when;//未来的超时时间
  int type;//闹钟类型，一次性的还是周期性的
  tasl_struct *p;//和哪个进程相关
  struct alarm *next;
}

然后OS用特定堆的数据结构方式管理，struct alarm *head

OS会周期性的检测这些闹钟，如果发现超时了OS就会给对应的进程发SIGALARM信号。

上面所说的所有信号的产生，都是由OS来执行，但是信号不一定立即处理，那么是什么时候被处理的呢？

进程退出时——核心转储

先来看一段代码：

#include <iostream>
#include <unistd.h>
#include <signal.h>
#include <sys/types.h>
#include <cstdlib>
using namespace std;
int main()
{
    while(true)
    {
        int arr[10];
        arr[100] = 106;//这里数组是越界的
    }
    return 0;
}

这里并没有显示越界的报错。

改成一千也没报错，但是i改成一万就报错了

这里是什么情况呢？因为开辟的栈区是合法的，只有到了为开辟的栈区才会进行报错。

像这种，Term这种是正常退出，而Core是退出之后还要做其他工作。

在云服务器上，默认如果进程是core退出的暂时看不到现象，想看到需要打开一个选项：

第一个core file size是0，这是云服务器默认的。

这里设置一下。

然后再次运行上面的段错误的代码：

并且还多出来了一个文件。

第一个后面多出来的core dumped就是核心转储操作，多出来的文件就是核心转储的内容。

多出来的文件.后缀是引起core问题进程的pid。

核心转储：当进程出现异常是hi后，我们将进程的对应时刻，在内存中的有效数据转储到磁盘中。（二进制临时文件）

作用就是为了更方便调试：

这里直接就帮助我们找到了问题。（这里叫做事后调试）

core-file core.xxx

信号的保存

有一个问题，如果所有信号都被捕捉了，那么这个信号是不是就无法停下来了呢？

#include <iostream>
#include <unistd.h>
#include <signal.h>
#include <sys/types.h>
#include <cstdlib>
using namespace std;
void catchSig(int signo)
{
    cout << "信号拦截：" << signo << endl;
}
int main()
{
    for(int signo = 1; signo <= 31; signo++)
    {
        signal(signo,catchSig);
    }
    while(true)
    {
        cout << "运行中" << getpid() << endl;
        sleep(1);
    }
    return 0;
}

最后用了kill -9才将这个进程杀掉。

OS中9号信号是无法进行捕捉的。

信号其它相关概念

实际执行信号处理的动作称为信号递达。

信号从生产到递达之间的状态称为信号未决（Pending）。

进程可以选择阻塞（Block）某个信号。

被阻塞的信号产生时将保持在未决状态，直到进程解除对此信号的阻塞才执行递达的动作。

注意,阻塞和忽略是不同的,只要信号被阻塞就不会递达,而忽略是在递达之后可选的一种处理动作。

并且，PCB中还有一个信号的函数指针数组，里面都是处理信号的方法。

我们使用的信号捕捉也只是将该数组中对应信号的方法给替换了，也就是替换了函数地址。

也就是说，如果要给信号产生，不妨碍他可以先被阻塞。

信号如何实现捕捉的

之前说信号只会在合适的时候才会被处理，不然就一直被保存在pending位图中。

从内核态返回用户态的时候，进行信号的处理。

我们平时是用户态，但是难免会去通过OS访问系统自身的资源和硬件资源，这个时候就要去进行系统调用才能完成：

也就是说，系统调用还要进行身份切换，会比调用用户层本身的方法慢。

所以避免频繁的使用系统调用。

并且，CPU中由寄存器会存储以下相关数据。

那么，一个进程怎么跑到OS中执行方法呢？

因为进程的独立性，所以每个进程都有一个用户级页表。

在开机的时候，操作系统要加载到内存中，因为操作系统只有一份，在内存中也只有一份，相对应的内核级页表也只有一份就够了。

CPU中也会有一个寄存器储存内核级页表，每个进程都会通过内核空间访问内核页表，然后去找到物理内存中的操作系统的代码和数据。

也就是说，进程要访问OS的接口，其实只需要在自己的地址空间上进行跳转就可以了。

如果想访问内核级数据，CPU的CR3要变成0才有权限。

那么是怎么进行切换的呢？是系统调用接口的起始位置会帮助我们进行切换。

也就会说前半段代码可能是用户态跑的，但是这里突然就变成内核态跑。

在Linux中，有一个叫Int 80 —— 陷入内核。

这个是汇编指令，这个就是修改当前进程在寄存器中CR3的身份状态。