---

   sigaction.3p    ( 3 )

---

Обоснование (Rationale)

Although this volume of POSIX.1‐2017 requires that signals that
       cannot be ignored shall not be added to the signal mask when a
       signal-catching function is entered, there is no explicit
       requirement that subsequent calls to sigaction() reflect this in
       the information returned in the oact argument. In other words, if
       SIGKILL is included in the sa_mask field of act, it is
       unspecified whether or not a subsequent call to sigaction()
       returns with SIGKILL included in the sa_mask field of oact.

       The SA_NOCLDSTOP flag, when supplied in the act->sa_flags
       parameter, allows overloading SIGCHLD with the System V semantics
       that each SIGCLD signal indicates a single terminated child. Most
       conforming applications that catch SIGCHLD are expected to
       install signal-catching functions that repeatedly call the
       waitpid() function with the WNOHANG flag set, acting on each
       child for which status is returned, until waitpid() returns zero.
       If stopped children are not of interest, the use of the
       SA_NOCLDSTOP flag can prevent the overhead from invoking the
       signal-catching routine when they stop.

       Some historical implementations also define other mechanisms for
       stopping processes, such as the ptrace() function. These
       implementations usually do not generate a SIGCHLD signal when
       processes stop due to this mechanism; however, that is beyond the
       scope of this volume of POSIX.1‐2017.

       This volume of POSIX.1‐2017 requires that calls to sigaction()
       that supply a NULL act argument succeed, even in the case of
       signals that cannot be caught or ignored (that is, SIGKILL or
       SIGSTOP).  The System V signal() and BSD sigvec() functions
       return [EINVAL] in these cases and, in this respect, their
       behavior varies from sigaction().

       This volume of POSIX.1‐2017 requires that sigaction() properly
       save and restore a signal action set up by the ISO C standard
       signal() function. However, there is no guarantee that the
       reverse is true, nor could there be given the greater amount of
       information conveyed by the sigaction structure. Because of this,
       applications should avoid using both functions for the same
       signal in the same process. Since this cannot always be avoided
       in case of general-purpose library routines, they should always
       be implemented with sigaction().

       It was intended that the signal() function should be
       implementable as a library routine using sigaction().

       The POSIX Realtime Extension extends the sigaction() function as
       specified by the POSIX.1‐1990 standard to allow the application
       to request on a per-signal basis via an additional signal action
       flag that the extra parameters, including the application-defined
       signal value, if any, be passed to the signal-catching function.