sigaction.2 (2010 09)

s
sigaction(2) sigaction(2)
Note that longjmp() and siglongjmp() are not in the list of reentrant functions. This is because
the code executing after longjmp() and siglongjmp()
can call any unsafe functions with the same
danger as calling those unsafe functions directly from the signal handler. Applications that use
longjmp() and siglongjmp() from within signal handlers require rigorous protection in order to be
portable.
Many of the other functions that are excluded from the list are traditionally implemented using either
malloc() or free() functions or the standard I/O library, both of which traditionally use data struc-
tures in a non-reentrant manner.
Because any combination of different functions using a common data structure can cause reentrancy
problems, this document does not define the behavior when any unsafe function is called in a signal
handler that interrupts an unsafe function.
If the signal occurs other than as the result of calling
abort(), kill(), sigqueue(),orraise(),
the behavior is undefined if the signal handler calls any function in the standard library other than one of
the functions listed in the table above or refers to any object with static storage duration other than by
assigning a value to a static storage duration variable of type volatile sig_atomic_t . Furthermore, if such
a call fails, the value of
errno is indeterminate.
Usually, the signal is executed on the stack that was in effect before the signal was delivered. An alter-
nate stack may be specified to receive a subset of the signals being caught.
When the signal handler returns, the receiving process will resume execution at the point it was inter-
rupted unless the signal handler makes other arrangements. If
longjmp() or _longjmp() is used to
leave the signal handler, then the signal mask must be explicitly restored by the process.
POSIX.4-1993 defines the third argument of a signal handling function when
SA_SIGINFO is set as a
void * instead of a ucontext_t *, but without requiring type checking. New applications should explicitly
cast the third argument of the signal handling function to uncontext_ t *.
The BSD optional four argument signal handling function is not supported by this specification. The BSD
declaration would be
void handler(int sig, int code, struct sigcontext *scp, char *addr);
where sig is the signal number, code is additional information on certain signals, scp is a pointer to the
sigcontext structure, and addr is additional address information. Much the same information is
available in the objects pointed to by the second argument of the signal handler specified when
SA_SIGINFO is set.
Threads Considerations
The signal disposition, catch/ignore/default, established by
sigaction() is shared by all threads in the
process.
If the signal disposition for sig is set to
SIG_IGN or is set to SIG_DFL and the default action for sig is to
ignore the signal, any instances of sig pending on the process or any of the threads will be discarded. The
signals are discarded regardless of whether the signal is blocked by any of the threads.
For more information regarding signals and threads, see signal (5).
RETURN VALUE
Upon successful completion,
sigaction() returns 0. Otherwise −1 is returned, errno is set to indi-
cate 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 sig-
nal 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 imple-
mentation 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).
6 Hewlett-Packard Company − 6 − HP-UX 11i Version 3: September 2010