HP-UX Reference (11i v2 03/08) - 2 System Calls (vol 5)

ManualsBrandsHP ManualsSoftwareHP-UX Reference Manuals

381

382

383

384

385

386

387

388

389

390

sigaction(2) sigaction(2)

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 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 princi-

ples 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 deﬁne 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(),orraise(),

the behaviour is undeﬁned 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 speciﬁed 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 deﬁnes 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 speciﬁcation. 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 speciﬁed 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).

FUTURE DIRECTIONS

The fpathconf() function is marked as an extension in the list of safe functions because it is not

included in the corresponding list in the ISO POSIX-1 standard, but it is expected to be added in a future

revision of that standard.

AUTHOR

sigaction() was derived from the IEEE POSIX 1003.1-1988 Standard.