HP-UX Reference (11i v2 03/08) - 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
,orSIGSEGV 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 func-
tion, with a single exception: when a signal interrupts an unsafe function and the signal-catching
function 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 con-
tinue at the point the process was stopped. If the action of the signal is to invoke a signal-catching func-
tion, the signal-catching function will be invoked; in this case the original function is said to be inter-
rupted 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.
[EFAULT] act or oact points to an invalid address. The reliable detection of this
error is implementation dependent.
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 docu-
ment, 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. Appli-
cations must still consider all effects of such functions on such things as data structures, files and process
state. In particular, application writers need to consider the restrictions on interactions when interrupt-
ing 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.
HP-UX 11i Version 2: August 2003 − 5 − Hewlett-Packard Company Section 2−−367