sigaction.2 (2010 09)

s
sigaction(2) sigaction(2)
• If SA_SIGINFO is set, the signal-catching function will be entered as:
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
,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, 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 func-
tion, with a single exception: when a signal interrupts an unsafe function and the signal-catching
function 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 indivi-
dually 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,
regardless of invocation from a signal-catching function. This is the only intended meaning of the state-
ment 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 particular, 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 pro-
grammatic 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.
HP-UX 11i Version 3: September 2010 − 5 − Hewlett-Packard Company 5