HP-UX Reference (11i v2 04/09) - 2 System Calls (vol 5)

s
sigaction(2) sigaction(2)
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 signal 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 pending.
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 signals, all in the range
SIGRTMIN to SIGRTMAX, are pending, the implementation delivers the pending unblocked signal with
the lowest signal number within that range. The selection order between realtime and nonrealtime sig-
nals, or between multiple pending nonrealtime signals, is unspecified. Signals generated by kill() or
other events that cause signals to occur, such as detection of hardware faults, alarm() timer expiration,
or terminal activity, and for which the implementation does not support queueing, will have no effect on
signals already queued for the same signal number.
Section 2−−370 Hewlett-Packard Company − 3 − HP-UX 11i Version 2: September 2004