SIGSET(2) SIGSET(2)
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.
SIGHUP hangup
SIGINT interrupt
SIGQUIT* quit
SIGILL* illegal instruction (not held when caught)
SIGTRAP* trace trap (not held when caught)
SIGABRT* abort
SIGFPE* floating point exception
SIGKILL kill (can not be caught or ignored)
SIGSYS* bad argument to system call
SIGPIPE write on a pipe with no one to read it
SIGALRM alarm clock
SIGTERM software termination signal
SIGUSR1 user-defined signal 1
SIGUSR2 user-defined signal 2
SIGCLD death of a child (see WARNING below)
SIGPWR power fail (see WARNING below)
SIGPOLL selectable event pending (see NOTES below)
SIGIO 23 input/output possible
Page 1 (last mod. 8/20/87)
SIGSET(2) SIGSET(2)
SIGURG 24 urgent condition on IO channel
[2]window size changes
SIGWINCH 25
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 has a unique value that matches no
declarable function.
SIGDFL - 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'' will be 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 will have 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
SIGIGN - ignore signal
Any pending signal sig is discarded and the system
signal action is set to ignore future occurrences of
this signal type.
SIGHOLD - 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
Page 2 (last mod. 8/20/87)
SIGSET(2) SIGSET(2)
sig occurs. In this case, sigset specifies that the process
will call 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 will be passed
as the only argument to the signal-catching handler. Before
calling the signal-catching handler, the system signal
action will be 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 will resume execution at the point it
was interrupted. However, when a signal is caught during a
read(2), a write(2), an open(2), or an ioctl(2) system call
during a sigpause system call, or during a wait(2) system
call that does not return immediately due to the existence
of a previously stopped or zombie process, the signal-
catching handler will be executed and then the interrupted
system call may return a -1 to the calling process with
errno set to EINTR.
Sighold and sigrelse are used to 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 will fail
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.
Page 3 (last mod. 8/20/87)
SIGSET(2) SIGSET(2)
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
WARNING
Two signals that behave differently than the signals
described above exist in this release of the system:
SIGCLD death of a child (reset when caught)
SIGPWR power 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 as follows:
SIGDFL - ignore signal
NOTE: The core file may be truncated to exclude data
and/or stack information if the file size is larger than
ulimit. (See ulimit(2).)
The signal is to be ignored.
SIGIGN - ignore signal
The signal is to be ignored. Also, if sig is
SIGCLD, the calling process's child processes will
not create zombie processes when they terminate
[see exit(2)].
function address - catch signal
If the signal is SIGPWR or SIGWINCH , 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 terminating child process will be
queued. The wait system call removes the first
entry of the queue. If the signal system call is
used with SIGCLD the signal handler is re-
attached, and, if the queue is not empty, SIGCLD
is re-raised before signal returns.
The SIGCLD affects two other system calls [wait(2), and
Page 4 (last mod. 8/20/87)
SIGSET(2) SIGSET(2)
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 will block until all
of the calling process's child processes
terminate; it will then return 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 will 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 will never receive
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.
ORIGIN
AT&T V.3
Page 5 (last mod. 8/20/87)