Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Use <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html" rel="noreferrer"><code>sigaction()</code></a> unless you've got very compelling reasons not to do so.</p> <p>The <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/signal.html" rel="noreferrer"><code>signal()</code></a> 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 <code>sigaction()</code> avoids - unless you use the flags explicitly added to <code>sigaction()</code> to allow it to faithfully simulate the old <code>signal()</code> behaviour.</p> <ol> <li>The <code>signal()</code> function does not (necessarily) block other signals from arriving while the current handler is executing; <code>sigaction()</code> can block other signals until the current handler returns.</li> <li>The <code>signal()</code> function (usually) resets the signal action back to <code>SIG_DFL</code> (default) for almost all signals. This means that the <code>signal()</code> 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.</li> <li>The exact behaviour of <code>signal()</code> varies between systems — and the standards permit those variations.</li> </ol> <p>These are generally good reasons for using <code>sigaction()</code> instead of <code>signal()</code>. However, the interface of <code>sigaction()</code> is undeniably more fiddly.</p> <p>Whichever of the two you use, do not be tempted by the alternative signal interfaces such as <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/sighold.html" rel="noreferrer"><code>sighold()</code></a>, <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigignore.html" rel="noreferrer"><code>sigignore()</code></a>, <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigpause.html" rel="noreferrer"><code>sigpause()</code></a> and <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigrelse.html" rel="noreferrer"><code>sigrelse()</code></a>. They are nominally alternatives to <code>sigaction()</code>, 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.</p> <p>Multi-threaded programs and signals is a whole other complicated story. <s>AFAIK, both <code>signal()</code> and <code>sigaction()</code> are OK in multi-threaded applications.</s></p> <p><a href="https://stackoverflow.com/users/1287251/cornstalks">Cornstalks</a> <a href="https://stackoverflow.com/questions/231912/what-is-the-difference-between-sigaction-and-signal/232711?noredirect=1#comment43835195_232711">observes</a>:</p> <blockquote> <p>The Linux man page for <a href="http://man7.org/linux/man-pages/man2/signal.2.html" rel="noreferrer"><code>signal()</code></a> says:</p> <p><code>&nbsp;&nbsp;</code><em>The effects of <strong><code>signal()</code></strong> in a multi-threaded process are unspecified.</em></p> <p>Thus, I think <code>sigaction()</code> is the only that can be used safely in a multi-threaded process. </p> </blockquote> <p>That's interesting. The Linux manual page is more restrictive than POSIX in this case. POSIX specifies for <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/signal.html" rel="noreferrer"><code>signal()</code></a>:</p> <blockquote> <p>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:</p> <ul> <li>The process calling <code>abort()</code>, <code>raise()</code>, <code>kill()</code>, <code>pthread_kill()</code>, or <code>sigqueue()</code> to generate a signal that is not blocked</li> <li>A pending signal being unblocked and being delivered before the call that unblocked it returns</li> </ul> <p>the behavior is undefined if the signal handler refers to any object other than <code>errno</code> with static storage duration other than by assigning a value to an object declared as <code>volatile sig_atomic_t</code>, or if the signal handler calls any function defined in this standard other than one of the functions listed in <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04" rel="noreferrer">Signal Concepts</a>.</p> </blockquote> <p>So POSIX clearly specifies the behaviour of <code>signal()</code> in a multi-threaded application.</p> <p>Nevertheless, <code>sigaction()</code> is to be preferred in essentially all circumstances — and portable multi-threaded code should use <code>sigaction()</code> 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.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload