【问题标题】:Is it possible to always catch signal even if program just started yet?即使程序刚刚开始,是否可以始终捕获信号?
【发布时间】:2015-04-21 15:10:41
【问题描述】:

我想捕捉发送到我的程序的信号并执行简单的操作(例如,使用指定的代码退出)。但是如果进程在我的信号处理程序设置之前接收到一个信号,它就会异常退出,就像不存在处理程序一样。

我的简单程序的源代码:

#include <signal.h>
#include <stdlib.h>
#include <unistd.h>

void handler(int sig) { exit(0); }

int main()
{
    signal(SIGTERM, handler);
    while(1) { sleep(1); }
    return 0;
}

使用g++ my.c 命令编译。

连续运行程序的脚本:

while true; do ./a.out; echo $?; done

如果我手动发送信号进行处理,那么大部分时间一切正常 - 以零代码退出。但如果我使用下面的脚本:

频繁发送信号到进程的脚本:

while true; do slay -sSIGTERM a.out; done

我收到了很多 Terminated 143 消息。

但如果我使用 gcc(而不是 g++),我无法使用非零退出代码来了解情况。

在这方面,我的问题是如何让一个 C++(g++ 编译)程序与 C(gcc 编译)程序有类似的行为?

最好采用最大标准化方法。

在 QNX 6.5、gcc 4.7.2 上测试

【问题讨论】:

    标签: c++ c gcc qnx signal-handling


    【解决方案1】:

    实现您想要的唯一方法是让父进程在分叉之前阻止所有信号 (sigprocmask),然后等到设置信号处理程序之后再解除阻止。任何纯粹在你自己的程序中的东西都是无用的,因为信号仍然可以到达父窗口和它执行的窗口之间。

    【讨论】:

    • 但是为什么在使用 c 而不是 c++ 时会有如此不同的行为呢?在 c++ 的情况下一些更复杂的初始化?是否可以简化?
    • 我认为只是由于执行的代码量不同而导致的时间不同。如果没有父母的帮助,您想要的行为是不可能,但这并不意味着失败很容易观察到。这就是短竞赛窗口的本质。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-12-04
    • 2020-05-26
    • 2023-03-08
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多