signal.5 (2010 09)

s
signal(5) signal(5)
to refer to the thread’s context at the
time of the interruption.
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.
It is possible for code to always be zero, and scp to always be
NULL.
The pointer scp, siginfop, and contextp are 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(),or
ioctl() on a slow device (such as a terminal, but not a file on a local filesystem), during a
pause()
system call or a wait() system call that does not return immediately 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].
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 pro-
cess, the process is continued, even if the SIGCONT signal is blocked or ignored. If SIGCONT is blocked
and not ignored, the signal 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 dis-
carded. Similarly, when
SIGCONT is posted to threads created with process contention scope, using
pthread_kill(), pending stop signals may not be discarded. However, stop and continue signals
posted to threads created with system contention scope, using pthread_kill()
, will continue to
adhere to the semantics described in the preceding paragraph.
SIGKILL is sent by the system if an exec() system call is unsuccessful and the original program has
already been deleted.
Threads Considerations
The following summarizes the signal model for threads:
A signal mask which specifies the signals blocked from delivery is associated with each thread.
The signal disposition, catch/ignore/default, is a process attribute and is shared by all threads in the
process.
If the signal action for a signal specifies termination, stop or continue, all threads within the process
are terminated, stopped or continued, respectively. This is the case regardless of whether the signal
was directed at the process or a specific thread within the process.
Signals which are generated by some action associated with a particular thread, such as an invalid
pointer dereference, will be delivered to the thread which caused the generation of the signal.
These signals are referred to as synchronously generated signals.
Signals that are posted to the process by
kill() or some asynchronous event such as terminal
activity will be delivered to exactly one thread in the process which does not block delivery of the
signal; if there is more than one eligible thread, which thread the signal is delivered to may not be
able to be determined by an application. If all threads in the process block the signal, then the sig-
nal remains pending on the process until a thread unblocks the signal, issues a sigwait() call for
the signal or sets the signal disposition to ignore the signal. These signals are referred to as asyn-
chronously generated signals.
A thread can post a signal to a particular thread in the same process using
pthread_kill().If
the thread which the signal is posted to blocks delivery of the signal, the signal remains pending on
the thread.
The
sigpending() function returns a union of the set of signals pending on the process and on
the calling thread.
HP-UX 11i Version 3: September 2010 − 7 − Hewlett-Packard Company 7