sigaction.2 (2010 09)

s
sigaction(2) sigaction(2)
signal mask and the value of the sa_mask for the signal being delivered unless
SA_NODEFER or
SA_RESETHAND is set, and then including the signal being delivered. If and when the user’s signal
handler returns normally, the original signal mask is restored.
Once an action is installed for a specific signal, it remains installed until another action is explicitly
requested (by another call to
sigaction()), until the
SA_RESETHAND flag causes resetting of the
handler, or until one of the exec functions is called.
If the previous action for sig had been established by
signal(), the values of the fields returned in the
structure pointed to by oact are unspecified, and in particular oact->sa_handler is not necessarily the
same value passed to
signal(). However, if a pointer to the same structure or a copy thereof is passed
to a subsequent call to sigaction() via the act argument, handling of the signal will be as if the origi-
nal call to
signal() were repeated.
If
sigaction() fails, no new signal handler is installed.
It is unspecified whether an attempt to set the action for a signal that cannot be caught or ignored to
SIG_DFL is ignored or causes an error to be returned with
errno set to [EINVAL].
A signal is said to be generated for (or sent to) a process when the event that causes the signal first
occurs. Examples of such events include detection of hardware faults, timer expiration and terminal
activity, as well as the invocation of
kill()
and sigqueue(). In some circumstances, the same event
generates signals for multiple processes.
Each process has an action to be taken in response to each signal defined by the system (see Signal
Actions). A signal is said to be delivered to a process when the appropriate action for the process and sig-
nal is taken.
During the time between the generation of a signal and its delivery, the signal is said to be pending.
Ordinarily, this interval cannot be detected by an application.
However, a signal can be blocked from delivery to a thread. If the action associated with a blocked sig-
nal is anything other than to ignore the signal, and if that signal is generated for the thread, the signal
will remain pending until either it is unblocked or the action associated with it is set to ignore the signal.
If the action associated with a blocked signal is to ignore the signal and if that signal is generated for the
process, it is unspecified whether the signal is discarded immediately upon generation or remains pend-
ing.
Each thread has a signal mask that defines the set of signals currently blocked from delivery to it. The
signal mask for a thread is initialized from that of its parent. The
sigaction(), sigprocmask()
,
and
sigsuspend() functions control the manipulation of the signal mask.
The determination of which action is taken in response to a signal is made at the time the signal is
delivered, allowing for any changes since the time of generation. This determination is independent of
the means by which the signal was originally generated. If a subsequent occurrence of a pending signal is
generated, it is implementation-dependent as to whether the signal is delivered more than once. The
order in which multiple, simultaneously pending signals are delivered to a process is unspecified.
When any stop signal (
SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) is generated for a process, any pend-
ing SIGCONT signals for that process will be discarded. Conversely, when SIGCONT is generated for a
process, all pending stop signals for that process will be discarded. When SIGCONT is generated for a
process that is stopped, the process will be continued, even if the SIGCONT signal is blocked or ignored.
If SIGCONT is blocked and not ignored, it will remain pending until it is either unblocked or a stop signal
is generated for the process.
Some signal-generating functions, such as high-resolution timer expiration, asynchronous I/O completion,
interprocess message arrival, and the
sigqueue() function, support the specification of an application-
defined value, either explicitly as a parameter to the function or in a sigevent structure parameter (see
signal (5)).
Realtime Signals Extension
When a signal is generated by
sigqueue() or any signal-generating function that supports the
specification of an application-defined value, and if the SA_SIGINFO flag is set for that signal, the signal
will be queued to the process along with the application-specified signal value.
Multiple occurrences of signals so generated are queued in FIFO order. When multiple unblocked sig-
nals, all in the range
SIGRTMIN to SIGRTMAX, are pending, the implementation delivers the pending
unblocked signal with the lowest signal number within that range.
HP-UX 11i Version 3: September 2010 − 3 − Hewlett-Packard Company 3