signal.5 (2010 09)

ManualsBrandsHP ManualsSoftwareHP-UX Manpages

signal(5) signal(5)

Each PTHREAD_SCOPE_SYSTEM thread may deﬁne an alternate signal handling stack. Use of

alternate signal stacks in PTHREAD_SCOPE_PROCESS threads will result in indeterminate

behavior.

Threadsafe Considerations

Refer to thread_safety(5) for a list of libc and libpthread interfaces which are not thread-safe, cancella-

tion points, cancel safe, async signal safe, and async cancel safe.

WARNINGS

The signals

SIGCLD and SIGPWR behave differently than those described above in the list of signals in

DESCRIPTION.

The actions for these signals is modiﬁed as follows:

SIGCLD Setting the action for SIGCLD to

SIG_IGN in a parent process prevents exiting

children of the calling process from creating a zombie process. If the parent process

executes the

wait() function, the calling process blocks until all of the child

processes of the calling processes terminate. The wait()

function then returns a

value of −1 with

errno set to [ECHILD] (see wait (2)).

If one of the signal interface routines is used to set the action for

SIGCLD to be

caught (that is, a function address is supplied) in a process that currently has ter-

minated (zombie) children, a

SIGCLD signal is delivered to the parent process

immediately.

Signal-catching functions set by

signal() are reset when the signal is caught.

These functions generally reinstall themselves. If the function associated with

SIGCLD reinstalls itself before it has called one of the child wait functions (such as

wait(), wait3(),orwaitpid()), another SIGCLD signal will be delivered and

the handler immediately invoked again (unless the signal is masked). Thus, a

signal-catching function for

SIGCLD should reinstall itself only after it has called

one of the child wait functions. (This similarly applies to signal-catching functions

set with

sigaction() where SA_RESETHAND or SV_RESETHAND has been

speciﬁed.)

SIGPWR The SIGPWR signal is sent to all processes after a power interruption when power is

restored and the system has done all necessary reinitialization. Processes restart by

catching (or ignoring) SIGPWR.

Applications that wish to recover from power failures should catch

SIGPWR and

take whatever necessary steps to reinitialize itself.

Some implementations do not generate

SIGPWR. Only systems with nonvolatile

memory can recover from power failures.

The hardware program counter is not advanced when a trap occurs. If the signal generated by a

hardware trap is received by a signal-catching function in the user program, the instruction that caused

the trap is re-executed upon return from the signal-catching function, causing the trap again, unless pro-

gram ﬂow is altered by the signal-catching function. For example, the

longjmp() routine (see

setjmp (3C)) can be called. Using longjmp() ensures software portability across different hardware

architectures.

If the signal generated by a hardware trap is not received by a signal-catching function, that is, if the sig-

nal is masked or ignored, there may be one of two results:

1. The instruction causing the trap is executed again, resulting in an inﬁnite program loop

2. The system detects the situation and causes the program to terminate.

AUTHOR

signal was developed by HP, AT&T, and the University of California, Berkeley.