当前位置：文江博客话题详情

UNIX 中的信号处理

发布于 2024-11-02 11:24:49 字数 45 浏览 0 评论 0原文

注册后处理信号。在信号处理函数中是否需要再次调用signal()来重新注册？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

天邊彩虹 2024-11-09 11:24:49

检查这个答案。或者特别是此链接。
基本上这取决于您的 UNIX 系统遵循的模型（BSD 或 System V）。

摘自信号手册页。

在原始的 Unix 系统中，当通过信号传递调用使用 signal() 建立的处理程序时，信号的处置将被重置
到 SIG_DFL，并且系统不会阻止该信号的进一步实例的传递。 System V 还为 signal() 提供了这些语义。这很糟糕，因为
在处理程序有机会重新建立自身之前，信号可能会再次传递。此外，相同信号的快速传递可能会导致递归
处理程序的调用。
BSD 通过更改信号处理的语义来改进这种情况（但不幸的是，在使用 signal() 建立处理程序时默默地更改了语义）。在 BSD 上，当调用信号处理程序时，信号处理不会重置，并且信号的进一步实例将被阻止传递，同时
处理程序正在执行。
Linux上的情况如下：
内核的 signal() 系统调用提供 System V 语义。
默认情况下，在 glibc 2 及更高版本中，signal() 包装函数不会调用内核系统调用。相反，它使用提供 BSD 语义的标志来调用 sigaction(2)。只要定义了 _BSD_SOURCE 功能测试宏，就会提供此默认行为。默认情况下，定义了_BSD_SOURCE；如果定义了 _GNU_SOURCE，它也是隐式定义的，当然也可以显式定义。
在 glibc 2 及更高版本上，如果未定义 _BSD_SOURCE 功能测试宏，则 signal() 提供 System V 语义。（如果在其中一种标准模式（-std=xxx 或 -ansi）中调用 gcc(1) 或定义各种其他功能测试宏，例如 _POSIX_SOURCE、_XOPEN_SOURCE 或 _SVID_SOURCE，则不会提供 _BSD_SOURCE 的默认隐式定义；请参阅 feature_test_macros (7).)
Linux libc4 和 libc5 中的 signal() 函数提供 System V 语义。如果 libc5 系统上包含而不是，则 signal() 提供 BSD 语义。

Check this answer. Or particularly this link.
Basically it depends on the model (BSD or System V) your unix system follows.

Extract from signal man page.

In the original Unix systems, when a handler that was established using signal() was invoked by the delivery of a signal, the disposition of the signal would be reset
to SIG_DFL, and the system did not block delivery of further instances of the signal. System V also provides these semantics for signal(). This was bad because the
signal might be delivered again before the handler had a chance to reestablish itself. Furthermore, rapid deliveries of the same signal could result in recursive
invocations of the handler.
BSD improved on this situation by changing the semantics of signal handling (but, unfortunately, silently changed the semantics when establishing a handler with signal()). On BSD, when a signal handler is invoked, the signal disposition is not reset, and further instances of the signal are blocked from being delivered while the
handler is executing.
The situation on Linux is as follows:
The kernel's signal() system call provides System V semantics.
By default, in glibc 2 and later, the signal() wrapper function does not invoke the kernel system call. Instead, it calls sigaction(2) using flags that supply BSD semantics. This default behavior is provided as long as the _BSD_SOURCE feature test macro is defined. By default, _BSD_SOURCE is defined; it is also implicitly defined if one defines _GNU_SOURCE, and can of course be explicitly defined.
On glibc 2 and later, if the _BSD_SOURCE feature test macro is not defined, then signal() provides System V semantics. (The default implicit definition of _BSD_SOURCE is not provided if one invokes gcc(1) in one of its standard modes (-std=xxx or -ansi) or defines various other feature test macros such as _POSIX_SOURCE, _XOPEN_SOURCE, or _SVID_SOURCE; see feature_test_macros(7).)
The signal() function in Linux libc4 and libc5 provide System V semantics. If one on a libc5 system includes instead of , then signal() provides BSD semantics.

回复收藏 0 原文

~没有更多了~