HP-UX Reference (11i v1 00/12) - 2 System Calls (vol 5)

__________________________________________________________________________________________________________________________________________________________________________________________________
__________________________________________________________________________________________________________________________________________________________________________________________________
STANDARD Printed by: Nora Chuang [nchuang] STANDARD
/build/1111/BRICK/man2/!!!intro.2
________________________________________________________________
___ ___
s
sigaction(2) sigaction(2)
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
shared data structures. 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. 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 structures 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 behaviour 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(),or
raise(),
the behaviour 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 alternate
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 applicationsshould explicitly cast the
third argument of the signal handlingfunction 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 avail-
able 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
Section 2−−338 − 6 − HP-UX Release 11i: December 2000
___
___