《Unix/Linux系统编程》教材学习笔记第六章

chapter6

信号和中断

“中断”是从I/O设备或协处理器发送到CPU的外部请求，它将CPU从正常执行转移到中断处理。与发送给CPU的中断请求一样，“信号”是发送给进程的请求，将进程从正常执行转移到中断处理。在讨论信号和信号处理之前，先来回顾中断的概念和机制，这有助于正确看待信号。

（1）首先，进程的概念概括为：一个“进程”就是一系列活动。广义的“进程”包括

* 从事日常事务的人。
* 在用户模式或内核模式下运行的Unix/Linux进程。
* 执行机器指令的CPU。

（2）“中断”是发送给“进程”的事件，它将“进程”从正常活动转移到其他活动，称为“中断处理”。“进程”可在完成“中断”处理后恢复正常活动。

（3）“中断”一词可应用于任何“进程”，并不仅限于计算机中的CPU。例如，我们可能会提到以下几种“中断”。

（3a）人员中断。

当我在办公室读书、评分、做白日梦时，可能会发生一些真实事件，比如:

所有这些事件都叫作人员中断，因为他们把人从正常活动转向“应对或处理中断”。处理完中断后，此人可以继续此前的活动（如果这个人还活着而且仍然记得自己之前的活动）。

每个中断都分配有一个唯一的ID识别号，并有一个预先安装的动作函数，人可在收到中断请求时“执行”动作函数。根据来源，中断可分为三类：

* 来自硬件的中断：大楼着火，闹钟响了等。
* 来自其他人的中断：电话响了，有人敲门等。
* 自己造成的中断：切到手指，吃得太多等。

按照紧急程度，中断可分为以下几类:

* 不可屏蔽(NMI)：大楼着火！
* 可屏蔽：有人敲门等。

人员的每个动作函数都是通过本能或经验实现的。由于人员中断的种类太多，所以不能在上表中全部列出，但是思路应该清晰。

（3b）进程中断。

这类中断是发送给进程的中断。当某进程正在执行时，可能会收到来自3个不同来源的中断：

* 来自硬件的中断：终端、间隔定时器的“Ctrl+C”组合键等。
* 来自其他进程的中断：kill(pid, SIG#)、death_of_child等。
* 自己造成的中断：除以0、无效地址等。

每个进程中断都被转换为一个唯一ID号，发送给进程。与多种类的人员中断不同，我们始终可限制在一个进程中的中断的数量。Unix/Linux中的进程中断称为信号，编号为1到31。进程的PROC结构体中有对应每个信号的动作函数，进程可在收到信号后执行该动作函数。与人员类似，进程也可屏蔽某些类型的信号，以推迟处理。必要时，进程还可能会修改信号动作函数。

（3c）硬件中断。

这类中断是发送给处理器或CPU的信号。它们也有三个可能的来源：

* 来自硬件的中断：定时器、I/O设备等。
* 来自其他处理器的中断：FFP、DMA、多处理器系统中的其他CPU。
* 自己造成的中断：除以0、保护错误、INT指令。

每个中断都有唯一的中断向量号。动作函数是中断向量表中的中断处理程序。CPU始终执行一个进程。CPU不会导致任何自己造成的中断（除非出错）。这种中断是由于进程正在使用或在大多数情况下误用CPU造成的。前一种情况包括INT n或等效指令，使CPU从用户模式切换到内核模式。后一种情况包括CPU识别为异常的所有陷阱错误。因此，可以排除CPU自身造成的中断，只留下CPU外部的中断。

（3d）进程的陷阱错误。

进程可能会自己造成中断。这些中断是由被CPU识别为异常的错误引起的，例如除以0、无效地址、非法指令、越权等。当进程遇到异常时，它会陷入操作系统内核，将陷阱原因转换为信号编号，并将信号发送给自己。如果在用户模式下发生异常，则进程的默认操作是终止，并使用一个可选的内存转储进行调试。进程可以用信号捕捉器代替默认动作函数，允许它在用户模式下处理信号。如果在内核模式下发生陷阱，原因一定是硬件错误，或者很可能是内核代码中的漏洞，在这种情况下，内核无法处理。在老版本的Unix/Linux中，内核只打印一条PANIC错误消息，然后就停止了。

Unix/Linux信号示例

（1）按“Ctrl+C”组合键通常会导致当前运行的进程终止。原因如下。“CtrI+C”组合键会生成一个键盘硬件中断。键盘中断处理程序将“Ctrl+C”组合键转换为SIGINT（2）信号，发送给终端上的所有进程，并唤醒等待键盘输人的进程。在内核模式下，每个进程都要检查和处理未完成的信号。进程对大多数信号的默认操作是调用内核的kexit(exitValue)函数来终止。在Linux中，exitValue的低位字节是导致进程终止的信号编号。

（2）用户可使用nohup a.out &命令在后台运行一个程序。即使在用户退出后，进程仍将继续运行。nohup命令会使sh像往常一样复刻子进程来执行程序，但是子进程会忽略SIGHUP（1）信号。当用户退出时，sh会向与终端有关的所有进程发送一个SIGHUP信号。后台进程在接收到这一信号后，会忽略它并继续运行。为防止后台进程使用终端进行I/O，后台进程通常会断开与终端的连接（通过将其文件描述符0、1、2重定向到/dev/null），使其完全不受任何面向终端信号的影响。

（3）几天后，用户再次登录时会发现（通过ps -u LTD）后台进程仍在运行。用户可以使用sh命令

kill pid(or kill -s 9 pid)

杀死该进程。方法如下。执行杀死的进程向pid标识的目标进程发送一个SIGTERM（15）信号，请求它死亡。目标进程将会遵从请求并终止。如果进程选择忽略SIGTERM信号，它可能拒绝死亡。在这种情况下，我们可以使用kill -s 9 pid，肯定能杀死它。因为进程不能修改对9号信号的动作。在最初的Unix中，只有9个信号。9号信号被保留为终止进程的终极手段。虽然后来的Unix/Linux系统将信号编号扩展到了31，但是信号编号9的含义仍然保留了下来。

Unix/Linux中的信号处理

信号类型

Unix/Linux支持31种不同的信号，每种信号在signal.h文件中都有定义。

#define SIGHUP      1
#define SIGINT      2
#define SIGQUIT     3
#define SIGILL      4
#define SIGTRAP     5
#define SIGABRT     6
#define SIGIOT      6
#define SIGBUS      7
#define SIGFPE      8
#define SIGKILL     9
#define SIGUSR1     10
#define SIGSEGV     11
#define SIGUSR2     12
#define SIGPIPE     13
#define SIGALRM     14
#define SIGTERM     15
#define SIGSTKFLT   16
#define SIGCHLD     17
#define SIGCONT     18
#define SIGSTOP     19
#define SIGTSTP     20
#define SIGTTIN     21
#define SIGTTOU     22
#define SIGURG      23
#define SIGXCPU     24
#define SIGXFSZ     25
#define SIGVTALRM   26
#define SIGPROF     27
#define SIGWINCH    28
#define SIGPOLL     29
#define SIGPWR      30
#define SIGSYS      31

每种信号都有一个符号名，如SIGHUP（1）、SIGINT（2）、SIGKILL（9）、SIGSEGV（11）等。

信号的来源

来自硬件中断的信号：在进程执行过程中，一些硬件中断被转换为信号发送给进程。硬件信号示例如下。

中断键（Ctrl+C），它产生一个SIGINT（2）信号。
间隔定时器，当它的时间到期时，会生成一个SIGALRM（14）、SIGVTALRM（26）或SIGPROF（27）信号。
其他硬件错误，如总线错误、IO陷阱等。

来自异常的信号：当用户模式下的进程遇到异常时，会陷入内核模式，生成一个信号，并发送给自己。常见的陷阱信号有SIGFPE（8），表示浮点异常（除以0），最常见也是最可怕的是SIGSEGV（11），表示段错误，等等。

来自其他进程的信号：进程可使用kill(pid, sig)系统调用向pid标识的目标进程发送信号。

在Linux下，运行简单的C程序

main(){while(1);}

使进程无限循环。从另一个（X-window）终端，使用ps -u查找循环进程pid。然后输入sh命令

kill -s 11 pid

循环进程会因为段错误而死亡。当某进程被某个信号终止时，它的exitValue就包含这个信号编号。父进程sh只是将死亡子进程的信号编号转换为一个错误字符串，不管它是什么。

进程PROC结构体中的信号

每个进程PROC都有一个32位向量，用来记录发送给进程的信号。在位向量中，每一位（0位除外）代表一个信号编号。此外，它还有一个信号MASK位向量，用来屏蔽相应的信号。可使用一系列系统调用，如sigmask、sigsetmask、siggetmask、sigblock等设置、清除和检查MASK位向量。待处理信号只在未被屏蔽的情况下才有效。这样可以让进程延迟处理被屏蔽的信号，类似于CPU屏蔽某些中断。

信号处理函数

每个进程PROC都有一个信号处理数组int sig[32]。sig[32]数组的每个条目都指定了如何处理相应的信号，其中0表示DEFault（默认），1表示IGNore（忽略），其他非零值表示用户模式下预先安装的信号捕捉（处理）函数。下图显示了信号位向量、屏蔽位向量和信号处理函数（信号处理的示意图）。

如果信号位向量中的位I为1，则会生成一个信号I或将其发送给进程。如果屏蔽位向量的位I为1，则信号会被阻塞或屏蔽。否则，信号未被阻塞。只有当信号存在并且未被阻塞时，信号才会生效或传递给进程。当内核模式下的进程发现一个未阻塞信号时，会将信号位清除为0，并尝试通过信号处理数组中的处理函数来处理该信号。0表示DEFault，1表示IGNore，其他数值表示用户空间内预先安装的捕捉函数。

安装信号捕捉函数

进程可使用系统调用：

int r = signal(int signal_number, void *handler);

来修改选定信号编号的处理函数，SIGKILL（9）和SIGSTOP（19）除外，它们不能修改。已安装的处理函数（若不是0或1）一定是以下形式用户空间中信号捕捉函数的入口地址：

void catcher(int signal_number){................}

signal()系统调用在所有类Unix系统中均可用，但它有一些不理想的特点。

（1）在执行已安装的信号捕捉函数之前，通常将信号处理函数重置为DEFault。为捕捉下次出现的相同信号，必须重新安装捕捉函数。这可能会导致下一个信号和信号处理函数重新安装之间出现竞态条件。相反，sigaction()在执行当前捕捉函数时会自动阻塞下一个信号，因此不会出现竞态条件。

（2）signal()不能阻塞其他信号。必要时，用户必须使用sigprocmask()显式地阻塞或解锁其他信号。相反，sigaction()可以指定要阻塞的其他信号。

（3）signal()只能向捕捉函数发送一个信号编号。sigaction()可以传输关于信号的其他信息。

（4）signal()可能不适用于多线程程序中的线程。sigaction()适用于线程。

（5）不同Unix版本的signal()可能会有所不同。sigaction()采用的是POSIX标准，可移植性更好。

由于这些原因，signal()已经被POSIX sigaction()函数所代替。在Linux（Bovet和Cesati 2005）中，sigaction()是一个系统调用。它的原型是：

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

sigaction结构体的定义为：

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：该字段是指向处理函数的指针，该函数与signal()的处理函数有相同的原型。
sa_sigaction：该字段是运行信号处理函数的另一种方法。它的信号编号旁边有两个额外参数，其中 siginfo_t *提供关于所接收信号的更多信息。
sa_mask：可在处理函数执行期间设置要阻塞的信号。
sa_flags：可修改信号处理进程的行为。若要使用sa_sigaction处理函数，必须将sa_flags设置为SA_SIGINFO。

在教材代码示例中会给出关于sigaction()系统调用的使用示例代码。

信号处理步骤

（1）当某进程处于内核模式时，会检查信号并处理未完成的信号。如果某信号有用户安装的捕捉函数，该进程会先清除信号，获取捕捉函数地址，对于大多数陷阱信号，则将已安装的捕捉函数重置为DEFault。然后，它会在用户模式下返回，以执行捕捉函数，以这种方式篡改返回路径。当捕捉函数结束时，它会返回到最初的中断点，即它最后进入内核模式的地方。因此，该进程会先迂回执行捕捉函数，然后再恢复正常执行。

（2）重置用户安装的信号捕捉函数：用户安装的陷阱相关信号捕捉函数用于处理用户代码中的陷阱错误。由于捕捉函数也在用户模式下执行，因此可能会再次出现同样的错误。如果是这样，该进程最终会陷入无限循环，一直在用户模式和内核模式之间跳跃。为了防止这种情况，Unix内核通常会在允许进程执行捕捉函数之前先将处理函数重置为DEFault。这意味着用户安装的捕捉函数只对首次出现的信号有效。若要捕捉再次出现的同一信号，则必须重新安装捕捉函数。但是，用户安装的信号捕捉函数的处理方法并不都一样，在不同Unix版本中会有所不同。例如，在BSD Unix中，信号处理函数不会被重置，但是该信号在执行信号捕捉函数时会被阻塞。

（3）信号和唤醒：在Unix/Linux内核中有两种SLEEP进程，即深度休眠进程和浅度休眠进程。前一种进程不可中断，而后一种进程可由信号中断。如果某进程处于不可中断的SLEEP状态，到达的信号（必须来自硬件中断或其他进程）不会唤醒进程。如果它处于可中断的SLEEP状态，到达的信号将会唤醒它。例如，当某进程等待终端输入时，它会以低优先级休眠，这种休眠是可中断的，SIGINT这类信号即可唤醒它。

信号与异常

Unix信号最初设计用于以下用途。

作为进程异常的统一处理方法：当进程遇到异常时，它会陷入内核模式，将陷阱原因转换为信号编号，并将信号发送给自己。如果在内核模式下发生异常，内核只打印一条PANIC错误消息，然后就停止了。如果在用户模式下发生异常，则进程通常会终止，并以内存转储进行调试。
让进程通过预先安装的信号捕捉函数处理用户模式下的程序错误。这类似于MVS[IBM MVS]中的ESPIE宏。
在特殊情况下，它会让某个进程通过信号杀死另一个进程。这里所说的杀死并不是直接杀死某个进程，而只是向目标进程发出“死亡”请求。

信号用作IPC

在许多操作系统的书籍中，信号被归类为进程间的通信机制。基本原理是一个进程可以向另一个进程发送信号，使它执行预先安装的信号处理函数。由于以下原因，这种分类即使不算不恰当也颇具争议。

该机制并不可靠，因为可能会丢失信号。每个信号由位向量中的一个位表示，只能记录一个信号的一次出现。如果某个进程向另一个进程发送两个或多个相同的信号，它们可能只在接收PROC中出现一次。实时信号被放入队列，并保证按接收顺序发送，但操作系统内核可能不支持实时信号。
竞态条件：在处理信号之前，进程通常会将信号处理函数重置为DEFault。要想捕捉同一信号的再次出现，进程必须在该信号再次到来之前重新安装捕捉函数。否则，下一个信号可能会导致该进程终止。在执行信号捕捉函数时，虽然可以通过阻塞同一信号来防止竞态条件，但是无法防止丢失信号。
大多数信号都有预定义的含义。不加区别地任意使用信号不仅不能达到通信的目的，反而会造成混乱。例如，向循环进程发送SIGSEGV(11)段错误信号，就像对水里游泳的人大喊：“你的裤子着火了！”

因此，试图将信号用作进程间通信手段实际上是对信号预期用途的过度延伸，应避免出现这种情况。

C语言程序中最常见的段错误的原因是解除空指针或无效指针关联、数组越界等。当某进程遇到无效内存异常时，它会陷入操作系统内核，生成SIGSEGV（11）信号，并发送给自己。SIGSEGV信号的默认处理函数是0，将导致进程终止。如果进程忽略该信号，它会再次返回同一错误指令，导致无限循环。若用户已经安装了SIGSEGV信号的捕捉函数，进程会执行信号捕捉函数，但是在执行结束后仍会返回同一错误指令。在任何段错误情况下，进程的唯一选择似乎只能是异常终止。在教材代码示例中会给出段错误捕捉函数的使用示例代码。

Linux中的IPC

IPC是指用于进程间通信的机制。在Linux中，IPC包含以下组成部分。

管道和FIFO

一个管道有一个读取端和一个写入端。管道的主要用途是连接一对管道写进程和读进程。管道写进程可将数据写入管道，读进程可从管道中读取数据。管道控制机制要对管道读写操作进行同步控制。未命名管道供相关进程使用。命名管道是FIFO的，可供不相关进程使用。在Linux中的管道读取操作为同步和阻塞。如果管道仍有写进程但没有数据，读进程会进行等待。

必要时，可通过对管道描述符的fcntl系统调用将管道操作更改为非阻塞。

信号

进程可使用kill系统调用向其他进程发送信号，其他进程使用信号捕捉函数处理信号。将信号用作IPC的一个主要缺点是信号只是用作通知，不含任何信息内容。

System V IPC

Linux支持System V IPC，包括共享内存、信号量和消息队列。在Linux中，多种System V IPC函数，例如用于添加/移除共享内存的shmat/shmdt、用于获取/操作信号量的semget/semop和用于发送/接收消息的msgsnd/msgrcv，都是库包装函数，它们都会向Linux内核发出一个ipc()系统调用。ipc()的实现是Linux所特有的，不可移植。