是什么的sigaction和信号之间的区别？ [英] What is the difference between sigaction and signal?

问题描述

我正要额外的信号处理程序添加到应用程序，我们在这里，我注意到，提交人使用的sigaction来设置其他信号处理程序。我打算用信号。按照惯例，我应该使用的sigaction但如果我是从头开始写，这是我应该选择？

I was about to add an extra signal handler to an app we have here and I noticed that the author had used sigaction to set up the other signal handlers. I was going to use signal. To follow convention I should use sigaction but if I was writing from scratch, which should I choose?

推荐答案

使用<一个href=\"http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html\"><$c$c>sigaction()除非你有非常令人信服的理由不这样做。

Use sigaction() unless you've got very compelling reasons not to do so.

的<一个href=\"http://pubs.opengroup.org/onlinepubs/9699919799/functions/signal.html\"><$c$c>signal()接口具有对其有利古代（因此可用性），它是在C标准中定义。然而，它有许多的不良特性的sigaction（）避免了 - 除非你使用标志明确地添加到的sigaction（）允许它忠实地模仿旧的信号（）行为。

The signal() interface has antiquity (and hence availability) in its favour, and it is defined in the C standard. Nevertheless, it has a number of undesirable characteristics that sigaction() avoids - unless you use the flags explicitly added to sigaction() to allow it to faithfully simulate the old signal() behaviour.

1. 的信号（）功能不（一定）从到达，而当前处理程序执行阻止其他信号; 的sigaction（）能阻挡其他信号，直到当前的处理程序返回。


2. 的信号（）功能（通常）复位信号动作回 SIG_DFL （默认值）几乎所有的信号。这意味着信号（）处理程序必须重新安装本身作为第一个动作。当检测到信号和处理程序重新安装期间，如果信号的第二个实例到达时，默认行为还开辟了时间之间脆弱的窗口（通常终止，有时带有prejudice - 又名核心转储）发生。


3. 信号（）的具体行为系统之间的变化 - 和标准，允许这些变化
。

1. The signal() function does not (necessarily) block other signals from arriving while the current handler is executing; sigaction() can block other signals until the current handler returns.
2. The signal() function (usually) resets the signal action back to SIG_DFL (default) for almost all signals. This means that the signal() handler must reinstall itself as its first action. It also opens up a window of vulnerability between the time when the signal is detected and the handler is reinstalled during which if a second instance of the signal arrives, the default behaviour (usually terminate, sometimes with prejudice - aka core dump) occurs.
3. The exact behaviour of signal() varies between systems — and the standards permit those variations.

这些通常是很好的理由使用的sigaction（）而不是的信号（）。然而，的sigaction（）的界面无疑是更繁琐。

These are generally good reasons for using sigaction() instead of signal(). However, the interface of sigaction() is undeniably more fiddly.

无论你用两个人，不要被诸如替代信号接口诱惑
<一href=\"http://pubs.opengroup.org/onlinepubs/9699919799/functions/sighold.html\"><$c$c>sighold(),
<一href=\"http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigignore.html\"><$c$c>sigignore(),
<一href=\"http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigpause.html\"><$c$c>sigpause()和
<一href=\"http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigrelse.html\"><$c$c>sigrelse().
他们名义上是替代的sigaction（），但他们只能勉强维持标准化，并在POSIX present的向后兼容性而不是严重的使用。请注意，POSIX标准说，他们在多线程程序的行为是不确定的。

Whichever of the two you use, do not be tempted by the alternative signal interfaces such as sighold(), sigignore(), sigpause() and sigrelse(). They are nominally alternatives to sigaction(), but they are only barely standardized and are present in POSIX for backwards compatibility rather than for serious use. Note that the POSIX standard says their behaviour in multi-threaded programs is undefined.

多线程程序和信号完全是另外复杂的故事。 据我所知，无论是信号（）和的sigaction（）都OK了在多线程应用程序。

Multi-threaded programs and signals is a whole other complicated story. AFAIK, both signal() and sigaction() are OK in multi-threaded applications.

玉米秆 <一个href=\"http://stackoverflow.com/questions/231912/what-is-the-difference-between-sigaction-and-signal/232711?noredirect=1#comment43835195_232711\">observes:

Linux手册页 信号（） 说：

The Linux man page for signal() says:

＆NBSP;＆NBSP; 的 信号（） 中的作用一个多线程程序是不确定的。的

因此​​，我觉得的sigaction（）是唯一可以安全地在多线程程序中使用。

Thus, I think sigaction() is the only that can be used safely in a multi-threaded process.

这很有趣。在Linux手册页面是在这种情况下，比POSIX更加严格。 POSIX指定<一个href=\"http://pubs.opengroup.org/onlinepubs/9699919799/functions/signal.html\"><$c$c>signal():

That's interesting. The Linux manual page is more restrictive than POSIX in this case. POSIX specifies for signal():

如果该过程是多线程的，或者如果该过程是单线程和比为的结果的其它执行的信号处理程序：

If the process is multi-threaded, or if the process is single-threaded and a signal handler is executed other than as the result of:

  
• 调用），加薪（）过程中止（，杀（）， pthread_kill（）或 sigqueue（）来产生不堵塞的信号

  
• 待处理的信号是畅通和畅通返回通话
前交付
  

• The process calling abort(), raise(), kill(), pthread_kill(), or sigqueue() to generate a signal that is not blocked
• A pending signal being unblocked and being delivered before the call that unblocked it returns

的行为是不确定的，如果信号处理程序是指除错误号与其他静态存储持续时间的任何对象不是声明为<$ C $对象赋值C>挥发性sig_atomic_t ，或者如果信号处理程序调用在此标准以外的在Signal概念的。

the behavior is undefined if the signal handler refers to any object other than errno with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t, or if the signal handler calls any function defined in this standard other than one of the functions listed in Signal Concepts.

所以POSIX明确规定的行为信号（）在多线程应用程序。

So POSIX clearly specifies the behaviour of signal() in a multi-threaded application.

然而，的sigaction（）是要在基本上所有的情况下pferred $ P $ - 便携式多线程code应该使用的sigaction（）除非有压倒性的原因，不能（如标准C语言只定义了使用的功能 - 是的，C11 code可以多线程）。这基本上就是这个答案的开篇也说。

Nevertheless, sigaction() is to be preferred in essentially all circumstances — and portable multi-threaded code should use sigaction() unless there's an overwhelming reason why it can't (such as "only use functions defined by Standard C" — and yes, C11 code can be multi-threaded). Which is basically what the opening paragraph of this answer also says.

这篇关于是什么的sigaction和信号之间的区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！