SIGNAL(5-SVR4) RISC/os Reference Manual SIGNAL(5-SVR4)
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 (or sent to) 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 or sigsend 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 sig-
info(5)].
Each process may specify a system action to be taken in
response to each signal sent 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, signal or sigset, or until
the process execs [see sigaction(2) and signal(2)]. When a
process execs, all signals whose disposition has been set to
catch the signal will be set to SIG_DFL. Alternatively, a
process may request that the system automatically reset the
disposition of a signal to SIG_DFL after it has been caught
[see sigaction(2) and signal(2)].
A signal is said to be delivered to a process when the
appropriate action for the process and signal is taken. Dur-
ing the time between the generation of a signal and its
delivery, the signal is said to be pending [see sigpend-
ing(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 sig-
nal is generated for the process, the signal is discarded
immediately upon generation.
Each process has a signal mask that defines the set of sig-
nals currently blocked from delivery to it [see sigproc-
mask(2)]. The signal mask for a process is initialized from
that of its parent.
Printed 11/19/92 Page 1
SIGNAL(5-SVR4) RISC/os Reference Manual SIGNAL(5-SVR4)
The determination of which action is 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 determi-
nation is independent of the means by which the signal was
originally generated.
The signals currently defined in <signal.h> are as follows:
Name Value Default Event
_________________________________________________________________________
SIGHUP 1 Exit Hangup [see termio(7)]
SIGINT 2 Exit Interrupt [see termio(7)]
SIGQUIT 3 Core Quit [see termio(7)]
SIGILL 4 Core Illegal Instruction
SIGTRAP 5 Core Trace/Breakpoint Trap
SIGABRT 6 Core Abort
SIGEMT 7 Core Emulation Trap
SIGFPE 8 Core Arithmetic Exception
SIGKILL 9 Exit Killed
SIGBUS 10 Core Bus Error
SIGSEGV 11 Core Segmentation Fault
SIGSYS 12 Core Bad System Call
SIGPIPE 13 Exit Broken Pipe
SIGALRM 14 Exit Alarm Clock
SIGTERM 15 Exit Terminated
SIGUSR1 16 Exit User Signal 1
SIGUSR2 17 Exit User Signal 2
SIGCHLD 18 Ignore Child Status Changed
SIGPWR 19 Ignore Power Fail/Restart
SIGWINCH 20 Ignore Window Size Change
SIGURG 21 Ignore Urgent Socket Condition
SIGPOLL 22 Exit Pollable Event [see streamio(7)]
SIGSTOP 23 Stop Stopped (signal)
SIGTSTP 24 Stop Stopped (user) [see termio(7)]
SIGCONT 25 Ignore Continued
SIGTTIN 26 Stop Stopped (tty input) [see termio(7)]
SIGTTOU 27 Stop Stopped (tty output) [see termio(7)]
SIGVTALRM 28 Exit Virtual Timer Expired
SIGPROF 29 Exit Profiling Timer Expired
SIGXCPU 30 Core CPU time limit exceeded [see getrlimit(2)]
SIGXFSZ 31 Core File size limit exceeded [see getrlimit(2)]
Using the signal, sigset or sigaction system call, a pro-
cess may specify one of three dispositions for a signal:
take the default action for the signal, ignore the signal,
or catch the signal.
Default Action: SIGDFL
A disposition of SIG_DFL specifies the default action. The
default action for each signal is listed in the table above
and is selected from the following:
Exit When it gets the signal, the receiving process is to
Page 2 Printed 11/19/92
SIGNAL(5-SVR4) RISC/os Reference Manual SIGNAL(5-SVR4)
be terminated with all the consequences outlined in
exit(2).
Core When it gets the signal, the receiving process is to
be terminated with all the consequences outlined in
exit(2). In addition, a ``core image'' of the pro-
cess is constructed in the current working direc-
tory.
Stop When it gets the signal, the receiving process is to
stop.
Ignore When it gets the signal, the receiving process is to
ignore it. This is identical to setting the dispo-
sition to SIG_IGN.
Ignore Signal: SIGIGN
A disposition of SIG_IGN specifies that the signal is to be
ignored.
Catch Signal: function address
A disposition that is a function address specifies that,
when it gets the signal, the receiving process is to execute
the signal handler at the specified address. Normally, the
signal handler is passed the signal number as its only argu-
ment; if the disposition was set with the sigaction func-
tion however, additional arguments may be requested [see
sigaction(2)]. When the signal handler returns, the receiv-
ing process resumes execution at the point it was inter-
rupted, unless the signal handler makes other arrangements.
If an invalid function address is specified, results are
undefined.
If the disposition has been set with the sigset or sigaction
function, the signal is automatically blocked by the system
while the signal catcher is executing. If a longjmp [see
setjmp(3C)] is used to leave the signal catcher, then the
signal must be explicitly unblocked by the user [see sig-
nal(2) and sigprocmask(2)].
If execution of the signal handler interrupts a blocked sys-
tem call, the handler is executed and the interrupted system
call returns a -1 to the calling process with errno set to
EINTR. However, if the SA_RESTART flag is set the system
call will be transparently restarted.
NOTES
The dispositions of the SIGKILL and SIGSTOP signals cannot
be altered from their default values. The system generates
an error if this is attempted.
Printed 11/19/92 Page 3
SIGNAL(5-SVR4) RISC/os Reference Manual SIGNAL(5-SVR4)
The SIGKILL and SIGSTOP signals cannot be blocked. The sys-
tem silently enforces this restriction.
Whenever a process receives a SIGSTOP, SIGTSTP, SIGTTIN, or
SIGTTOU signal, regardless of its disposition, any pending
SIGCONT signal are discarded.
Whenever a process receives a SIGCONT signal, regardless of
its disposition, any pending SIGSTOP, SIGTSTP, SIGTTIN, and
SIGTTOU signals is discarded. In addition, if the process
was stopped, it is continued.
SIGPOLL is issued when a file descriptor corresponding to a
STREAMS [see intro(2)] file has a ``selectable'' event pend-
ing. A process must specifically request that this signal
be sent using the I_SETSIG ioctl call. Otherwise, the pro-
cess will never receive SIGPOLL.
If the disposition of the SIGCHLD signal has been set with
signal or sigset, or with sigaction and the SA_NOCLDSTOP
flag has been specified, it will only be sent to the calling
process when its children exit; otherwise, it will also be
sent when the calling process's children are stopped or con-
tinued due to job control.
The name SIGCLD is also defined in this header file and
identifies the same signal as SIGCHLD. SIGCLD is provided
for backward compatibility, new applications should use
SIGCHLD.
The disposition of signals that are inherited as SIG_IGN
should not be changed.
SEE ALSO
exit(2), getrlimit(2), intro(2), kill(2), pause(2), sigac-
tion(2), sigaltstack(2), signal(2), sigprocmask(2), sig-
send(2), sigsuspend(2), wait(2), sigsetops(3C), siginfo(5),
ucontext(5).
Page 4 Printed 11/19/92