Linux----Signals

什么是信号？

​ 其实在之前学习的任何一种编程结构当中，可以这样子去解释：当你在看到代码的时候你完全是可以推测这段代码的执行时序的，因为无非就是一些循环，或者选择这样子的语句存在于代码中。即便是学习了fork()或者线程库的一些关于条件变量的那些并发模型代码之后，在进程或者线程之间的代码执行时序仍然是可以预测的！这可以简单的理解为”伪并发“。

​ 假设现在你在编写一个服务器代码，而用户在终端输入ctrl+c之后，会退出当前的进程。那么这种情况下，作为服务端而言是无法揣测客户端，客户的退出行为会在何时发生的！而在Linux系统中，就引入了信号的机制！·

​ 在事件发生的时间线上你无法揣测一个进程的一个操作会对另一个进程带来的瞬时影响，这个有的时候是无法预测的，那么信号的存在就是：让一个进程先去注册一些必要的，用来处理另一个进程发送信号的代码（sigHandler()函数）。当在这个进程执行的过程中，如果收到了另一个进程发送的信号，那么这个进程就会用这个注册的代码去处理哪些发送过来的信号！（其实这个接收信号的进程也可以理解为内核或者一些应用层的进程）可以见得，这个注册的过程其实就是对一些意外发生情况的预测，即：当我在接收到这些信号的时候我会如何去做！

​ 当然一个进程在发送一个信号的时候，也会出现一些特殊的情况，比如所谓的挂起与阻塞的状态。因为信号在发送的过程中，很多时候接收方并不一定会完美的接收到的这个发送出去的信号，这样发送端进程所发送的信号就变成了已发送但未被接收的信号，这就是所谓的挂起的信号，从而进入一个挂起队列，并在一个合适的时间从挂起队列再次出发，发送出去！但是在挂起队列中，同类型的信号只可以有一个，后续来的相同类型的信号会被丢弃，其实不难发现这样子的信号机制其实是不足够健壮的进程间通信机制，因为有的信号是会被丢弃的。

​ 这里就会有一个问题，当我们遇到那种会被阻塞的某种系统调用时（也许这个阻塞就是因为某种信号的到达所发送的阻塞现象），所以我们在进行判断的时候要引起一个注意：这个阻塞是系统调用发生错误的中断还是被信号阻塞了的中断？比如：对文件读的系统调用read()，如果read()的过程中被内核或者某个进程所发出的信号中断了，那么此时我们就应该考虑需不需要在阻塞结束之后再次进行read()的系统调用，让这个被信号阻塞中断的系统调用再次恢复。这是我们值得考虑的一个问题。