信号之不可靠的信号及中断的系统调用
一、不可靠的信号
在早期的UNIX版本中，信号是不可靠的。不可靠在这里指的是，信号可能会丢失：一个信号发生了，但进程却可能一直不知道这一点。
早期版本中的一个问题是在进程每次接到信号对其进行处理时，随即将该信号动作复位为默认值（经测试，发现我现在用的Red Hat Linux 2.6.18也是这样处理的。）。在描述这些早期系统的编程书籍中，有一个经典实例，它与如何处理中断信号相关，其代码与下面所示的相似：
int sig_int(); /* my signal handling function */ ... signal(SIGINT, sig_int); /*establish handler */ ... sig_int() { signal(SIGINT, sig_int); /* restablish handler for next time */ ... /* process the signal ... */ }
（由于早期的C语言版本不支持ISO C的void数据类型，所以将信号处理程序声明为int类型。）
这段代码的一个问题是：从信号发生之后到在信号处理程序中调用signal函数之前这段时间中有一个时间窗口。在此段时间中，可能发生另一次中断信号。第二个中断信号会导致执行默认动作，而针对中断信号的默认动作是终止该进程。这种类型的程序段在大多数情况下会正常工作，使得我们认为它们是正确无误的，而实际上并非如此。
二、中断的系统调用
早期UNIX系统的一个特性是：如果进程在执行一个低速系统调用而阻塞期间捕捉到一个信号，则该系统调用就被中断不再继续执行。该系统调用返回出错，其errno被设置为EINTR。
在这里，我们必须区分系统调用和函数。当捕捉到某个信号时，被中断的是内核中执行的系统调用。
为了支持这种特性，将系统调用分成两类：低速系统调用和其他系统调用。低速系统调用是可能会使进程永远阻塞的一类系统调用，它们包括：
- 在读某些类型的文件（管道、终端设备以及网络设备）时，如果数据不存在则可能会使调用者永远阻塞。
- 在写这些类型的文件时，如果不能立即接受这些数据，则也可能会使调用者永远阻塞。
- 打开某些类型文件，在某种条件发生之前也可能会使调用者阻塞（例如，打开终端设备，它要等待直到所有连接的调制解调器应答了电话）。
- pause（它使调用进程休眠直至捕捉到一个信号）和wait函数。
- 某些ioctl函数。
- 某些进程间通信函数。
在这些低速系统调用中，一个值得注意的例外是与磁盘I/O有关的系统调用。虽然读写一个磁盘文件可能暂时阻塞调用者（在磁盘驱动器将请求排入队列，然后在适当时间执行请求期间），但是除非发生硬件错误，I/O操作总会很快返回，并使调用者不再处于阻塞状态。
与被中断的系统调用相关的问题是必须显式地处理出错返回。典型的代码序列（假定进行一个读操作，它被中断，我们希望重新启动它）可能如下所示：
again: if ((n = read(fd, buf, BUFFSIZE) < 0) { if (errno == EINTR) goto again; /* just an interrupt system call */ /* handle other errors */ }
为了帮助应用程序使其不必处理被中断的系统调用，4.2BSD引入了某些被中断系统调用的自动重启动。自动重启动的系统调用包括ioctl、read、readv、write、writev、wait和waitpid。其中，前5个函数只有对低速设备进行操作时才会被信号中断。而wait和waitpid在捕捉到信号时总是被中断。4.3BSD允许进程基于每个信号禁用此功能。
本篇博文内容摘自《UNIX环境高级编程》（第二版），仅作个人学习记录所用。关于本书可参考：http://www.apuebook.com/。
