изучить и изменить сигнальное действие (examine and change a signal action)
Использование в приложениях (Application usage)
The sigaction() function supersedes the signal() function, and
should be used in preference. In particular, sigaction() and
signal() should not be used in the same process to control the
same signal. The behavior of async-signal-safe functions, as
defined in their respective DESCRIPTION sections, is as specified
by this volume of POSIX.1‐2017, regardless of invocation from a
signal-catching function. This is the only intended meaning of
the statement that async-signal-safe functions may be used in
signal-catching functions without restrictions. Applications must
still consider all effects of such functions on such things as
data structures, files, and process state. In particular,
application developers need to consider the restrictions on
interactions when interrupting sleep() and interactions among
multiple handles for a file description. The fact that any
specific function is listed as async-signal-safe does not
necessarily mean that invocation of that function from a signal-
catching function is recommended.
In order to prevent errors arising from interrupting non-async-
signal-safe function calls, applications should protect calls to
these functions either by blocking the appropriate signals or
through the use of some programmatic semaphore (see semget(3p),
sem_init(3p), sem_open(3p), and so on). Note in particular that
even the ``safe'' functions may modify errno; the signal-catching
function, if not executing as an independent thread, should save
and restore its value in order to avoid the possibility that
delivery of a signal in between an error return from a function
that sets errno and the subsequent examination of errno could
result in the signal-catching function changing the value of
errno. Naturally, the same principles apply to the async-signal-
safety of application routines and asynchronous data access. Note
that longjmp() and siglongjmp() are not in the list of async-
signal-safe functions. This is because the code executing after
longjmp() and siglongjmp() can call any unsafe functions with the
same danger as calling those unsafe functions directly from the
signal handler. Applications that use longjmp() and siglongjmp()
from within signal handlers require rigorous protection in order
to be portable. Many of the other functions that are excluded
from the list are traditionally implemented using either malloc()
or free() functions or the standard I/O library, both of which
traditionally use data structures in a non-async-signal-safe
manner. Since any combination of different functions using a
common data structure can cause async-signal-safety problems,
this volume of POSIX.1‐2017 does not define the behavior when any
unsafe function is called in a signal handler that interrupts an
unsafe function.
Usually, the signal is executed on the stack that was in effect
before the signal was delivered. An alternate stack may be
specified to receive a subset of the signals being caught.
When the signal handler returns, the receiving thread resumes
execution at the point it was interrupted unless the signal
handler makes other arrangements. If longjmp() or _longjmp() is
used to leave the signal handler, then the signal mask must be
explicitly restored.
This volume of POSIX.1‐2017 defines the third argument of a
signal handling function when SA_SIGINFO is set as a void *
instead of a ucontext_t *, but without requiring type checking.
New applications should explicitly cast the third argument of the
signal handling function to ucontext_t *.
The BSD optional four argument signal handling function is not
supported by this volume of POSIX.1‐2017. The BSD declaration
would be:
void handler(int sig, int code, struct sigcontext *scp,
char *addr);
where sig is the signal number, code is additional information on
certain signals, scp is a pointer to the sigcontext structure,
and addr is additional address information. Much the same
information is available in the objects pointed to by the second
argument of the signal handler specified when SA_SIGINFO is set.
Since the sigaction() function is allowed but not required to set
SA_NODEFER when the application sets the SA_RESETHAND flag,
applications which depend on the SA_RESETHAND functionality for
the newly installed signal handler must always explicitly set
SA_NODEFER when they set SA_RESETHAND in order to be portable.
See also the rationale for Realtime Signal Generation and
Delivery in the Rationale (Informative) volume of POSIX.1‐2017,
Section B.2.4.2, Signal Generation and Delivery.
