HP-UX Reference (11i v1 05/09) - 2 System Calls (vol 5)

s
sigaction(2) sigaction(2)
The behaviour of a process is undefined after it returns normally from a signal- catching function
for a SIGBUS, SIGFPE, SIGILL,or
SIGSEGV signal that was not generated by kill() or
raise().
The system will not allow a process to catch the signals
SIGKILL and SIGSTOP.
If a process establishes a signal-catching function for the
SIGCHLD
signal while it has a ter-
minated child process for which it has not waited, it is unspecified whether a
SIGCHILD signal is
generated to indicate that child process.
When signal-catching functions are invoked asynchronously with process execution, the behaviour
of some of the functions defined by this document is unspecified if they are called from a
signal-catching function.
Refer to the "Async Signal Safe" section of thread_safety(5) which defines a set of functions that are
either reentrant or not interruptible by signals. Therefore applications may invoke them, without
restriction, from signal-catching functions.
All functions not mentioned under the "Async Signal Safe" section of thread_safety(5) are con-
sidered to be unsafe with respect to signals. In the presence of signals, all functions defined by this
document will behave as defined when called from or interrupted by a signal-catching function,
with a single exception: when a signal interrupts an unsafe function and the signal-catching func-
tion calls an unsafe function, the behaviour is undefined.
Signal Effects on Other Functions
Signals affect the behaviour of certain functions (defined under the "Async Signal Safe" section of
thread_safety(5)) if delivered to a process while it is executing such a function. If the action of the signal is
to terminate the process, the process will be terminated and the function will not return. If the action of the
signal is to stop the process, the process will stop until continued or terminated. Generation of a
SIGCONT
signal for the process causes the process to be continued, and the original function will continue at the point
the process was stopped. If the action of the signal is to invoke a signal-catching function, the signal-
catching function will be invoked; in this case the original function is said to be interrupted by the signal.
If the signal-catching function executes a return statement, the behaviour of the interrupted function will
be as described individually for that function. Signals that are ignored will not affect the behaviour of any
function; signals that are blocked will not affect the behaviour of any function until they are unblocked and
then delivered.
RETURN VALUE
Upon successful completion,
sigaction() returns 0. Otherwise 1 is returned, errno is set to indicate
the error and no new signal-catching function will be installed.
ERRORS
The sigaction() function will fail if:
[EINVAL] The sig argument is not a valid signal number or an attempt is made to catch a signal
that cannot be caught or ignore a signal that cannot be ignored.
The sigaction() function may fail if:
[EINVAL] An attempt was made to set the action to SIG_DFL for a signal that can-
not be caught or ignored (or both).
APPLICATION USAGE
The sigaction() function supersedes the signal() interface, and should be used in preference. In
particular, sigaction() and signal() should not be used in the same process to control the same
signal. The behaviour of reentrant functions, as defined in the description, is as specified by this document,
regardless of invocation from a signal-catching function. This is the only intended meaning of the statement
that reentrant functions may be used in signal-catching functions without restrictions. Applications must
still consider all effects of such functions on such things as data structures, files and process state. In partic-
ular, application writers need to consider the restrictions on interactions when interrupting sleep() and
interactions among multiple handles for a file descriptor. The fact that any specific function is listed as
reentrant does not necessarily mean that invocation of that function from a signal-catching function is
recommended.
In order to prevent errors arising from interrupting non-reentrant function calls, applications should pro-
tect calls to these functions either by blocking the appropriate signals or through the use of some program-
matic semaphore. This document does not address the more general problem of synchronizing access to
HP-UX 11i Version 1: September 2005 5 Hewlett-Packard Company Section 2359