HP-UX Reference (11i v3 07/02) - 2 System Calls (vol 5)

s
sigaction(2) sigaction(2)
void func(int signo, siginfo_t *siginfo, void *ucontextptr);
where func is the specified signal-catching function,
signo is the signal number of the signal
being delivered, siginfo points to an object of type siginfo_t associated with the signal being
delivered, and
ucontextptr points to a ucontext_t .
• The behavior 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, a
SIGCHLD signal is delivered to the parent
process immediately.
• When signal-catching functions are invoked asynchronously with process execution, the behavior 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 behavior is undefined.
Signal Effects on Other Functions
Signals affect the behavior 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. Gen-
eration 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 behavior of the interrupted function will be as described individu-
ally for that function. Signals that are ignored will not affect the behavior of any function; signals that are
blocked will not affect the behavior of any function until they are unblocked and then delivered.
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 behavior of reentrant functions, as defined in the description, is as specified by this document, regard-
less 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 particu-
lar, 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 shared data struc-
tures. Note in particular that even the "safe" functions may modify the global variable errno; the
signal-catching function may want to save and restore its value. Naturally, the same principles apply to
the reentrancy of application routines and asynchronous data access.
426 Hewlett-Packard Company − 5 − HP-UX 11i Version 3: February 2007