HP-UX Reference (11i v1 00/12) - 2 System Calls (vol 5)

__________________________________________________________________________________________________________________________________________________________________________________________________
__________________________________________________________________________________________________________________________________________________________________________________________________
STANDARD Printed by: Nora Chuang [nchuang] STANDARD
/build/1111/BRICK/man2/!!!intro.2
________________________________________________________________
___ ___
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, handlingof the signal will be as if the original 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 signal
is taken.
During the time between the generation of a signal and its delivery, the signal is said to be pending. Ordi-
narily, this interval cannot be detected by an application. However, a signal can be blocked from delivery
to a process. If the action associated with a blocked signal is anything other than to ignore the signal, and if
that signal is generated for the process, 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 dis-
carded immediately upon generation or remains pending.
Each process has a signal mask that defines the set of signals currently blocked from delivery to it. The
signal mask for a process 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 gen-
erated, 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 pro-
cess 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 sig-
nals so generated are queued in FIFO order. When multiple unblocked signals, all in the range SIGRT-
MIN
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 signals, 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 ter-
minal activity, and for which the implementation does not support queueing, will have no effect on signals
already queued for the same signal number.
HP-UX Release 11i: December 2000 − 3 − Section 2−−335
___
___