HP-UX Reference (11i v2 04/09) - 5 Miscellaneous Topics (vol 9)

s
signal(5) signal(5)
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 (2) 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.
Each thread may define an alternate signal handling stack.
Threadsafe Considerations
Refer to thread_safety(5) for a list of libc and libpthread interfaces which are not thread-safe, cancella-
tion points, cancel safe, async signal safe, and async cancel safe.
LWP Considerations
A signal mask which specifies the signals blocked from delivery is associated with each Lightweight Pro-
cess (LWP).
The signal disposition, catch/ignore/default, is a process attribute and is shared by all LWPs in the pro-
cess.
An LWP can post a signal to a particular LWP in the same process using
lwp_kill(). If the thread
which the signal is posted to blocks delivery of the signal, the signal remains pending on the thread.
Each LWP may define an alternate signal handling stack.
SEE ALSO
alarm(2), ioctl(2), kill(2), sigaction(2), sigaltstack(2), siginterrupt(2), signal(2), sigpending(2), sigproc-
mask(2), sigstack(2), sigsuspend(2), sigwait(2), thread_safety(5), wait(2), waitid(2).
CHANGE HISTORY
First released in Issue 1.
Issue 4
The following changes are incorporated for alignment with the ISO POSIX-1 standard:
• The function declarations in this header are expanded to full ISO C prototypes.
• The DESCRIPTION section is changed:
- to define the type sig_atomic_t
- to define the syntax of signal names and functions
- to combine the two tables of constants
-
SIGFPE is no longer limited to floating-point exceptions, but covers all erroneous arithmetic
operations.
The following change is incorporated for alignment with the ISO C standard:
• The
raise() function is added to the list of functions declared in this header.
Other changes are incorporated as follows:
• A reference to
<sys/types.h> is added for the definition of pid_t . This is marked as an
extension.
• In the list of signals starting with
SIGCHLD, the statement "but a system not supporting the job
control option is not obliged to support the functionality of these signals" is removed. This is
because job control is defined as mandatory on Issue 4 conforming implementations.
HP-UX 11i Version 2: September 2004 − 6 − Hewlett-Packard Company Section 5−−325