问题标签 [signal-handling]

为什么sem_wait不能在信号处理程序中使用（特别是每个线程的 SIGSEGV 信号）？有人可以给我一个示例场景，它会使应用程序崩溃吗？我想sem_wait这既是可重入的又是线程安全的，那么这里的问题是什么？为什么它不是异步安全的？

我正在构建一个 django 应用程序，它依赖于一个已实现 SIGINT 信号处理程序的 python 模块。

假设我无法更改我所依赖的模块，我该如何解决“信号仅在主线程中有效”错误我将它集成到 Django 中？

我可以在 Django 主线程上运行它吗？有没有办法禁止处理程序允许模块在非主线程上运行？

谢谢！

如果我向以下程序发送多个后续Hangup信号，则只会处理其中两个，其余的将被忽略：

我使用以下命令向进程发送信号：

如果我连续三次运行上述命令，第三个信号将被忽略，如下面的输出：

有什么办法也可以捕捉到第三个信号吗？

我正在编写一个必须处理信号的 shell 程序。我的相关信号处理相关代码如下：

编译给了我以下警告和错误：

谁能告诉我为什么会收到这些警告和错误？

使用信号处理程序的正确方法是什么？

我从这个问题中看到了下面的代码，想知道为什么还需要放入signal(SIGSEGV,sig_func);sig_func 中？当进程接收到 SIGSEGV 信号时，这不会创建一个无休止的循环吗？

我正在编写一个使用套接字的 API。在 API 中，我为各种项目分配内存。我想确保关闭套接字并释放内存，以防出现 Ctrl-C 等信号。在对此进行研究时，似乎 free() 不在安全函数列表（man 7 信号）中，因此，我无法释放信号处理程序内的内存。我可以关闭套接字就好了。有人对如何释放内存有任何想法吗？提前感谢您的宝贵时间。

有人能告诉我从 Signal Handler 调用 syscall(SYS_gettid) 会产生什么不利影响吗？我知道它不在从信号处理程序调用的安全函数列表中，但我想知道它背后的原因？

我已经制作了跟随信号处理程序

如何删除或阻止这个特定的处理程序，以便我可以设置另一个使用相同信号的信号处理程序？谢谢。

当用 C 或 Perl 编程时，SIGALRM 信号可以中断“打印”，从而只发生部分写入。

使用 Java 时，信号是否存在这样的麻烦？或者 JVM 是否保护程序员免受任何副作用？

首先，当数据准备好读取时，我无法让我的串行设备生成 SIGIO。

我正在尝试编写一个简单的串行接口，以使用 USB 到串行适配器与微型通信。我想让这个接口与你在微控制器中找到的接口相似（中断驱动，使用回调），所以我决定采用捕获 SIGIO 信号的方式，而不是使用单独的线程或恒定的非阻塞串行读。这是我的初始化代码（大部分在各种异步串行教程中看起来很熟悉）：

byteCallback 是我的信号处理程序。我已经通过手动向进程发送信号来验证它是否有效。我正在与之通信的 micro 不支持任何类型的流控制，因此被禁用。我已经验证我可以使用标准读/写系统调用从设备读取和写入。

问题是当数据进入时，信号处理程序不会被调用。我怀疑这是因为 SIGIO 仅在收到 CR 或行尾字符时生成。由于这完全是原始模式并且没有发送此类字符，因此不会生成 SIGIO。目前我只在 OSX 上尝试过，但理想情况下，相同的代码也可以在 linux 上运行。

任何帮助，将不胜感激。我已经搜索了很多，人们总是建议只使用 select() 或其他方法。这几乎成了一个挑战，我还没有准备好放弃。

谢谢。