signal(5) DG/UX R4.11MU05 signal(5)
NAME
signal - base signals
SYNOPSIS
#include <signal.h>
DESCRIPTION
A signal is an asynchronous notification of an event. A signal is
said to be generated for a process when the event associated with
that signal first occurs. Examples of such events include hardware
faults, timer expiration and terminal activity, as well as the
invocation of the kill, sigsend, or sigsendset system calls. In some
circumstances, the same event generates signals for multiple
processes. A process may request a detailed notification of the
source of the signal and the reason why it was generated [see
siginfo(5)].
A signal is said to be delivered to a process when the appropriate
action for the process and signal is taken. During the time between
the generation of a signal and its delivery, the signal is said to be
pending [see sigpending(2)]. Ordinarily, this interval cannot be
detected by an application. However, a signal can be blocked from
delivery to a process [see signal(2) and sigprocmask(2)]. If the
action associated with a blocked signal is anything other than to
ignore the signal, and if that signal is generated for the process,
the signal remains pending until either it is unblocked or the
signal's disposition requests that the signal be ignored. If the
signal disposition of a blocked signal requests that the signal be
ignored, and if that signal is generated for the process, the signal
is discarded immediately upon generation.
Note that a process must enter the kernel in order to take delivery
of a signal. The generation of a signal does not cause a process to
move from user space into the kernel. Ordinarily, a process enters
the kernel by making a system call, but it will also enter the kernel
if (1) its timeslice runs out, (2) it is preempted by a higher
priority process, (3) it takes an exception, or (4) the processor on
which it is running receives a hardware interrupt.
Each process may specify a system action to be taken in response to
each signal delivered to it, called the signal's disposition. The
set of system signal actions for a process is initialized from that
of its parent. Once an action is installed for a specific signal, it
usually remains installed until another disposition is explicitly
requested by a call to either sigaction or any of its associated
calls or until the process execs [see sigaction(2) and signal(2)].
When a process execs, all signals whose dispositions have been set to
catch the signal will be set to SIGDFL. Alternatively, a process
may request that the system automatically reset the disposition of a
signal to SIGDFL after it has been caught [see sigaction(2)].
Each process has a signal mask that defines the set of signals
currently blocked from delivery to it [see sigprocmask(2)]. The
signal mask for a process is initialized from that of its parent.
The determination of which action will be taken in response to a
signal is made at the time the signal is delivered, allowing for any
changes since the time of generation. This determination is
independent of the means by which the signal was originally
generated.
For a list of the signals supported by DG/UX, see <sys/signal.h>.
If the signal occurs other than as the result of calling the abort or
raise function, the behavior is undefined if the signal handler calls
any function that is not safe with respect to signals or refers to
any object with static storage duration other than by assigning a
value to a static storage duration variable of type volatile
sigatomict.
The functions listed in the following table are safe with respect to
signals. Applications may invoke them, without restriction, from
signal handlers.
_exit fstat read sysconf
access getegid rename tcdrain
alarm geteuid rmdir tcflow
cfgetispeed getgid setgid tcflush
cfgetospeed getgroups setpgid tcgetattr
cfsetispeed getpgrp setsid tcgetpgrp
cfsetospeed getpid setuid tcsendbreak
chdir getppid sigaction tcsetattr
chmod getuid sigaddset tcsetpgrp
chown kill sigdelset time
close link sigemptyset times
creat lseek sigfillset umask
dup2 mkdir sigismember uname
dup mkfifo sigpending unlink
execle open sigprocmask utime
execve pathconf sigsuspend wait
fcntl pause sleep waitpid
fork pipe stat write
In addition, the signal function is safe with respect to signals if
it is called with a first argument of the signal number corresponding
to the signal that caused the invocation of the handler.
All other functions are considered unsafe with respect to signals.
If any function that is unsafe is interrupted by a signal handler
that then calls any function that is unsafe, the behavior is
undefined.
SEE ALSO
kill(2), pause(2), sigaction(2), sigset(2), sigaltstack(2),
signal(2), sigprocmask(2), sigsend(2), sigsuspend(2), wait(2),
psiginfo(3C), psignal(3C), sigsetops(3C), siginfo(5), ucontext(5).
Licensed material--property of copyright holder(s)