NAME

sigset, sighold, sigrelse, sigignore, sigpause − signal management

SYNOPSIS

#include <signal.h>

void (∗sigset (sig, func))()
int sig;
void (∗func)(); int sighold (sig)
int sig; int sigrelse (sig)
int sig; int sigignore (sig)
int sig; int sigpause (sig)
int sig;

DESCRIPTION

These functions provide signal management for application processes.  sigset specifies the system signal action to be taken upon receipt of signal sig. This action is either calling a process signal-catching handler func or performing a system-defined action. 

sig can be assigned any one of the following values except SIGKILL.  Machine or implementation dependent signals are not included (see NOTES below).  Each value of sig is a macro, defined in <signal.h>, that expands to an integer constant expression. 

SIGHUP01hangup
SIGINT02interrupt (rubout)
SIGQUIT03 ∗quit (ASCII FS)
SIGILL04 ∗illegal instruction (not reset when caught)
SIGTRAP05 ∗trace trap (not reset when caught)
SIGIOT06 ∗IOT instruction (obsolete)
SIGABRT06 ∗used by abort, replaces SIGIOT
SIGEMT07 ∗EMT instruction (obsolete)
SIGFPE08 ∗floating point exception
SIGKILL09kill (cannot be caught or ignored)
SIGBUS10 ∗bus error
SIGSEGV11 ∗segmentation violation
SIGSYS12 ∗bad argument to system call
SIGPIPE13write on a pipe with no one to read it
SIGALRM14alarm clock
SIGTERM15software termination signal
SIGUSR116user-defined signal 1
SIGUSR217user-defined signal 2
SIGCLD18death of a child
SIGPWR19power fail restart
SIGWIND20window change
SIGURG21urgent condition on an I/O channel
SIGPOLL22selectable event pending
SIGSTOP23sendable stop signal, not from tty
SIGTSTP24stop signal from tty
SIGTTIN25process stop by background tty read
SIGTTOU26process stop by background tty write
SIGCONT27continue a stopped process
SIGXCPU28exceeded CPU time limit
SIGXFSZ29exceeded file size limit
SIGVTALRM30virtual time alarm
SIGPROF31profiling time alarm

See below under SIG_DFL regarding asterisks (∗) in the above list. 

The following values for the system-defined actions of func are also defined in <signal.h>. Each is a macro that expands to a constant expression of type pointer to function returning void and contains a unique value that matches no declarable function. 

SIG_DFL −  default system action

Upon receipt of the signal sig, the receiving process is to be terminated with all of the consequences outlined in exit(2). In addition a “core image” is made in the current working directory of the receiving process if sig is one for which an asterisk appears in the above list and the following conditions are met:

The effective user ID and the real user ID of the receiving process are equal. 

An ordinary file named core exists and is writable or can be created.  If the file must be created, it inherits the following properties:

a mode of 0666 modified by the file creation mask [see umask(2)]

a file owner ID that is the same as the effective user ID of the receiving process. 

a file group ID that is the same as the effective group ID of the receiving process

SIG_IGN −  ignore signal

Any pending signal sig is discarded and the system signal action is set to ignore future occurrences of this signal type. 

SIG_HOLD − hold signal

The signal sig is to be held upon receipt.  Any pending signal of this type remains held.  Only one signal of each type is held. 

Otherwise, func must be a pointer to a function, the signal-catching handler, that is to be called when signal sig occurs.  In this case, sigset specifies that the process calls this function upon receipt of signal sig. Any pending signal of this type is released. This handler address is retained across calls to the other signal management functions listed here.

When a signal occurs, the signal number sig is passed as the only argument to the signal-catching handler.  Before calling the signal-catching handler, the system signal action is set to SIG_HOLD .  During normal return from the signal-catching handler, the system signal action is restored to func and any held signal of this type released.  If a non-local goto (longjmp) is taken, then sigrelse must be called to restore the system signal action and release any held signal of this type. 

In general, upon return from the signal-catching handler, the receiving process resumes execution at the point it was interrupted.  However, when a signal is caught during a read(2), write(2), open(2), or an ioctl(2) system call during a sigpause or wait(2) that does not return immediately due to the existence of a previously stopped or zombie process, the signal-catching handler is executed and then the interrupted system call may return a −1 to the calling process with errno set to EINTR. 

sighold and sigrelse establish critical regions of code.  sighold is analogous to raising the priority level and deferring or holding a signal until the priority is lowered by sigrelse. sigrelse restores the system signal action to that specified previously by sigset.

sigignore sets the action for signal sig to SIG_IGN (see above). 

sigpause suspends the calling process until it receives a signal, the same as pause(2). However, if the signal sig had been received and held, it is released and the system signal action taken.  This system call is useful for testing variables that are changed on the occurrence of a signal.  The correct usage is to use sighold to block the signal first, then test the variables.  If they have not changed, then call sigpause to wait for the signal. 

sigset fails if one or more of the following are true:

­[EINVAL] sig is an illegal signal number (including SIGKILL) or the default handling of sig cannot be changed. 

­[EINTR] A signal was caught during the system call sigpause.

DIAGNOSTICS

Upon successful completion, sigset returns the previous value of the system signal action for the specified signal sig. Otherwise, a value of SIG_ERR is returned and errno is set to indicate the error.  SIG_ERR is defined in <signal.h>.

For the other functions, upon successful completion, a value of 0 is returned.  Otherwise, a value of −1 is returned and errno is set to indicate the error. 

SEE ALSO

kill(2), pause(2), signal(2), wait(2), setjmp(3C). 

WARNING

Two signals behave differently from the signals described above:

SIGCLDdeath of a child (reset when caught)
SIGPWRpower fail (not reset when caught)

For these signals, func is assigned one of three values: SIG_DFL, SIG_IGN, or a function address. The actions prescribed by these values are listed below:

SIG_DFL − ignore signal

The signal is to be ignored. 

SIG_IGN − ignore signal

The signal is to be ignored.  Also, if sig is SIGCLD, the calling process’s child processes do not create zombie processes when they terminate [see exit(2)].

function address − catch signal

If the signal is SIGPWR, the action to be taken is the same as that described above for func equal to function address. The same is true if the signal is SIGCLD with one exception: while the process is executing the signal-catching function, any received SIGCLD signals is ignored.  (This is the default action.) 

The SIGCLD affects two other system calls [wait(2), and exit(2)] in the following ways:

wait If the func value of SIGCLD is set to SIG_IGN and a wait is executed, the wait blocks until all of the calling process’s child processes terminate; it then returns a value of −1 with errno set to ECHILD. 

exit If in the exiting process’s parent process the func value of SIGCLD is set to SIG_IGN , the exiting process does not create a zombie process. 

When processing a pipeline, the shell makes the last process in the pipeline the parent of the proceeding processes.  A process that may be piped into in this manner (and thus become the parent of other processes) should take care not to set SIGCLD to be caught. 

NOTES

SIGPOLL is issued when a file descriptor corresponding to a STREAMS [see intro(2)] file has a “selectable” event pending.  A process must specifically request that this signal be sent using the I_SETSIG ioctl(2) call [see streamio(7)].  Otherwise, the process never receives SIGPOLL. 

For portability, applications should use only the symbolic names of signals rather than their values and use only the set of signals defined here.  The action for the signal SIGKILL can not be changed from the default system action. 

Specific implementations may have other implementation-defined signals.  Also, additional implementation-defined arguments may be passed to the signal-catching handler for hardware-generated signals.  For certain hardware-generated signals, it may not be possible to resume execution at the point of interruption. 

The signal type SIGSEGV is reserved for the condition that occurs on an invalid access to a data object.  If an implementation can detect this condition, this signal type should be used. 

The other signal management functions, signal(2) and pause(2), should not be used in conjunction with these routines for a particular signal type.

September 02, 1992