Open System Services System Calls Reference Manual (G06.25+, H06.03+)
Files signal(4)
A process can elect to ignore the delivery of some signals, while allowing the system to perform
default actions upon the delivery of other signals. The system also allows processes to install
process-specific signal-catching functions.
During the time between the generation of a signal and its delivery, the signal is said to be pend-
ing. Usually, 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 remains pending until either it is unblocked or the action associated with it is
set to ignore the signal. If the action associated with the 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; applications should therefore not depend on
whether the signal is discarded 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 to that of its parent. The sigaction(), sigproc-
mask(), 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 discarded and only one instance
of the same signal remains pending; however, because this action is likely to change in future
releases, users should not rely on this behavior. The order in which pending signals are delivered
to a process is unspecified and should not be relied upon.
When any stop signal (SIGSTOP, SIGTSTP, SIGTTIN,orSIGTTOU) is generated for a pro-
cess, any pending SIGCONT signal for that process is discarded. Conversely, when SIGCONT
is generated for a process, all pending stop signals for that process are discarded even if these
signals are being caught.
When SIGCONT is generated for a process that is stopped, the process continues, even if the
SIGCONT signal is blocked or ignored. If SIGCONT is blocked and not ignored, it remains
pending until either it is unblocked or a stop signal is generated for the process.
When SIGUNCP is generated, the action taken allows an H-series process to control what hap-
pens when the process does not offer frequent enough opportunities to synchronize blade ele-
ments. Either the process can call a user signal-handler function, or the following actions are
defined:
SIG_ABORT The process terminates abnormally.
SIG_DEBUG The process enters the debugger so that an appropriate location for a voluntary
rendezvous opportunity can be identified.
SIG_DFL The signal is ignored by the process, but the system suspends the process until an
EMS event is generated for logging by the $ZLOG distributor.
SIG_IGN The signal is ignored by the process and no EMS event is generated.
When a signal handler is invoked (which normally only happens to allow debugging), the process
should call sigaction() to set SIG_IGN or SIG_DFL or simply return. It is undefined what hap-
pens if the signal is rearmed and siglongjmp() is called before the synchronization completes:
the process might suspend or it might abend.
Signals reserve the last 1000 words of the user stack. When a SIGSTK signal is delivered, the
system cuts back the stack to the start of the last 1000 words. If user data is present in the last
1000 words of the stack, that data is lost.
527186-003 Hewlett-Packard Company 11−21