изучить и изменить сигнальное действие (examine and change a signal action)
Обоснование (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.
