signal() ：任何性能影响？答案

【问题标题】：signal() : any performance impact?signal() ：任何性能影响？
【发布时间】：2015-06-01 06:07:10
【问题描述】：

当我无法控制的事情发生故障并且程序需要退出时，我需要捕获 SIGABRT, SIGSEGV and SIGILL 以向用户显示适当的严重错误消息。

但是我的程序做了很多实时计算，所以性能很重要。

signal() (http://www.cplusplus.com/reference/csignal/signal/) 是否会导致任何performance loss（某种持续监控？）或根本不会（仅在发生异常时触发，否则不会丢失性能）。

编辑：我的软件在 Windows（7 及更高版本）和 OS X（10.7 及更高版本）上运行。

【问题讨论】：

在传递信号时调用信号处理程序，AFAIK 没有现代操作系统为此使用轮询。如果您需要更好地理解底层机制，我建议您好好阅读Advanced Programming in the Unix Environment...
答案可能在很大程度上取决于环境。所以你可能想告诉我们你的程序使用的操作系统、编译器和其他相关的东西。
我的软件在 Windows（7 及更高版本）和 OS X（10.7 及更高版本）上运行

标签： c++ c exception signals segmentation-fault

【解决方案1】：

如果您的时间要求严格的流程捕捉到信号，则不会浪费“特殊”时间。实际上，内核为您的进程保存了一个信号和操作表，如果发送了信号，它必须通过这些表。但是每一种向进程发送消息或调用处理程序的方式都需要时间。消息队列或等待“标志”将具有几乎相同的“浪费”。

但使用信号可能会产生其他应提及的含义。如果信号到达，几乎每个系统调用都会被中断。调用的返回值为EINTR。如果您有许多信号传递给您的进程，这可能会大大降低您的应用程序的速度，因为您必须始终检查EINTR 并再次进入系统调用。而且每个系统调用都有点昂贵。因此，使用EINTR 返回值在系统调用上循环很多可能是一个糟糕的设计。

但对于您的问题，您只需查找SIGABRT、SIGSEGV 和SIGILL。这些信号通常只用于很少的例外情况。所以不要害怕根据需要使用它们。但要避免为自己的 IPC 频繁使用这些信号。这是可以做到的，但这是非常糟糕的设计。对于用户 IPC，有更好的信号名称和更好的方法。

简而言之：对于仅捕获异常信号，您在这里没有任何时间紧迫的问题。

【讨论】：

太好了，感谢您的明确回答。为了清楚起见，我将这些例外情况用于我的程序访问错误的音频或图形驱动程序的罕见情况，从而导致我无法控制的崩溃。
那是它的确切用例:-)如果您认为答案是正确的，您应该接受答案:-) 谢谢！ ;)
@user3767622 - 值得一提的是，几乎每个操作系统都将使用 SIGABRT、SIGSEGV 和 SIGILL 的默认信号处理程序启动进程，因为这些默认情况下是致命信号，会导致进程退出。您所做的只是用自己的信号处理程序替换现有的信号处理程序。