HP-UX Reference (11i v1 05/09) - 5 Miscellaneous Topics (vol 9)

s
signal(5) signal(5)
G Ignore the signal. Do not terminate or stop the receiving process.
H Stop the receiving process. While a process is stopped, any additional signals
sent to the process are suspended until the process is restarted (except those
marked with Note F above, which are processed immediately). However,
when the process is restarted, pending signals are processed. When a process
that is in an orphaned process group (see glossary(9)) receives a
SIGTSTP,
SIGTTIN,orSIGTTOU signal, the process is not stopped because a process in
an orphaned process group is not allowed to stop. Instead, a
SIGHUP signal is
sent to the process, and the
SIGTSTP
, SIGTTIN,orSIGTTOU is discarded.
SIG_IGN Ignore the signal.
When one of the supported signal interface routines is used to set the action of a signal to
SIG_IGN and an instance of the signal is pending, the pending signal is cleared.
D Signals marked with Note D above cannot be ignored.
address Catch the signal.
Upon receipt of the signal, if signal()
is used to set the action, reset the action for the
signal caught to
SIG_DFL (except signals marked with Note C). Then, call the signal-
catching function to which address points, and resume executing the receiving process at
the point where it was interrupted. Signal interface routines other than signal() nor-
mally do not reset the action for the signal caught. However, sigaction() and
sigvector() provide a way of specifying this behavior (see sigaction(2) or sigvec-
tor(2)).
The signal-catching function is called with the following three parameters:
sig The signal number.
code A word of information usually provided by the hardware.
scp A pointer to the machine-dependent structure sigcontext defined in
<signal.h> .
Depending on the value of sig, code can be zero and/or scp can be
NULL. The meanings of
code and scp and the conditions determining when they are other than zero or
NULL are
implementation-dependent (see
DEPENDENCIES below). It is possible for code to always
be zero, and scp to always be
NULL.
The pointer scp is valid only during the context of the signal-catching function.
Optional parameters can be omitted from the signal-catching function parameter list, in
which case the signal-catching function is exactly compatible with
UNIX System V. Truly
portable software should not use the optional parameters in signal-catching routines.
Upon return from the signal-catching function, the receiving process resumes execution
at the point where it was interrupted.
When a signal is caught during the execution of system calls such as
read(),
write(), open(),orioctl() on a slow device (such as a terminal, but not a file),
during a pause() system call or a wait() system call that does not return immedi-
ately because a previously stopped or zombie process already exists, the signal-catching
function is executed and the interrupted system call returns a 1 to the calling process
with errno set to EINTR.
C If the signal is marked with Note C above, the action is not reset to SIG_DFL before calling
the signal-catching function. Furthermore, the action is not reset if any signal interface rou-
tine other than signal() was used to set the action. See the description of signal catching
above.
E If the signal is marked with Note E above, the signal cannot be caught.
When any stop signal (SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) is generated for a process, pending
SIGCONT signals for that process are discarded. Conversely, when SIGCONT is generated for a process,
all pending stop signals for that process are discarded. When SIGCONT is generated for a stopped process,
the process is continued, even if the SIGCONT signal is blocked or ignored. If SIGCONT is blocked and not
ignored, the process remains pending until it is either unblocked or a stop signal is generated.
Note: When any stop signal (SIGSTOP, SIGTSTP, SIGTIN, SIGTTOU) is posted to threads created with
process contention scope, using pthread_kill(), pending SIGCONT signals may not be discarded.
HP-UX 11i Version 1: September 2005 2 Hewlett-Packard Company Section 5351