防止信号处理失灵

核心提示： 第二步：发信号向某个进程发信号有三种方式：进程通过条用 raise() 显式地发送信号给自己； 信号从另一个进程发送，比方说通过 kill() 系统调用或者 Perl 脚本； 信号从内核发送，防止信号处理失灵(2)，例如，当进程试图存取不属于自己的内存，在过去的三十年中出现了几个可以信号处

第二步：发信号

向某个进程发信号有三种方式：

进程通过条用 raise() 显式地发送信号给自己；

信号从另一个进程发送，比方说通过 kill() 系统调用或者 Perl 脚本；

信号从内核发送。例如，当进程试图存取不属于自己的内存，或在系统关闭期间存取内存时；

第三步：产生和处理信号

下面程序注册 SIGTERM 处理器。然后产生一个 SIGTERM 信号，从而导致该处理器运行：

#include <csignal>
#include <iostream>
using namespace std;
void term(int sig)
{
　　//..necessary cleanup operations before terminating
　　cout << "handling signal no." <<sig <<endl;
}
int main()
{
　　signal(SIGTERM, term); // register a SIGTERM handler
　　raise(SIGTERM); // will cause term() to run
}　　　　ANSI <signal.h> 的局限

当进入就绪状态的某个进程准备运行一个 SIGx 信号处理例程时又接收到另一个 SIGx 信号，这时会发生什么情况呢？一个方法是让内核中断该进程并再次运行该信号处理例程。为此，这个处理例程必须是可重入的（re-entrant）。但是，设计可重入的处理例程决非易事。ANSI C 解决重现信号（recurring signals）问题的方法是在执行用户定义的处理例程前，将处理例程重置为 STG_DFL。这样做是有问题的。

当两个信号快速产生时，内核运行第一个信号的处理例程，而对第二个信号则进行默认处理，这样有可能终止该进程。

在过去的三十年中出现了几个可以信号处理框架，每一种框架对重现信号的处理问题提供了不同的解决方法。POSIX 信号 API 是其中最为成熟的和可移植的一个。