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, sigsend, or sigqueue 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)]. 

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, sigset, or sigvec, or until the process execs [see sigaction(2), signal(2), sigset(2), and sigvec(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.  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. 

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 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 determination is independent of the means by which the signal was originally generated. 

CX/UX supports reliable signals as described in IEEE Std. 1003.4 Draft 12.  Signals are queued when the SA_SIGINFO flag is set.  See sigaction(2).  This feature and its application interfaces are subject to change if necessary to conform to the completed P1003.4 specification. 

Signals and Dispositions

The signals currently defined in <signal.h> are shown in the following table.  In the “Reference” column, the symbol “P” means that the signal name is defined by IEEE Std. 1003.1-1990 (POSIX), the symbol “P4” means that the signal is defined by IEEE Std. 1003.4 Draft 12, and the symbol “S” means that the signal name is defined by the System V Interface Definition, Third Edition. Signal names with neither symbol originate either with the Berkeley Software Distribution, SunOS, or CX/UX.  Portable applications should confine themselves to using only the signals referenced in the relevant standards. 

Using the signal, sigset, sigvec, or sigaction system call, a process may use one of the values listed below (defined in <signal.h>) to specify one of three dispositions for a signal: take the default action for the signal, ignore the signal, or catch the signal. 

SIG_DFL
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 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 process is constructed in the current working directory if 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 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. 

­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 disposition to SIG_IGN. 

SIG_IGN
A disposition of SIG_IGN specifies that the signal is to be ignored. 

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 argument; but CX/UX provides additional arguments which provide further information about the cause of the signal and the context in which it was generated.  The signal handler interface is described below. 

Usually, the stack used by the signal handler is the same stack that was in effect before the signal was delivered.  An alternate stack may be specified to receive a subset of the signals being caught [see sigaction(2), sigaltstack(2), and sigstack(2)]. 

The calling process may optionally specify a set of signals to be blocked by the system while the handler is executing, which may optionally include the signal itself [see sigaction(2)].  If the disposition has been set with the sigset, sigvec, 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 signal(2) and sigprocmask(2)]. 

If the signal handler was installed using signal(2) or if the SA_RESETHAND flag was used with sigaction(2), the disposition for signals other than SIGILL, SIGTRAP, and SIGPWR will be reset to SIG_DFL when the signal handler begins. 

When the signal handler returns, the receiving process resumes execution at the point it was interrupted, unless the signal handler makes other arrangements.  If an invalid function address is specified, results are undefined. 

If execution of the signal handler interrupts a blocked system call, for example a read(2), write(2), open(2), or ioctl(2) on a slow device, a pause(2), a sigtimedwait(2), or a wait(2) that does not return immediately, then 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 [see sigaction(2)] or sigvec was used, the system call will be transparently restarted. 

The dispositions of the SIGKILL and SIGSTOP signals cannot be altered from their default values.  The system generates an error if this is attempted. 

The SIGKILL and SIGSTOP signals cannot be blocked.  The system 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. 

The signals that a hardware exception may generate are SIGSEGV, SIGILL, SIGBUS, SIGTRAP, and SIGFPE.  If one of these signals is generated due to an exception when the signal is blocked, the behavior is unpredictable. 

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 continued due to job control. 

If the disposition of the SIGCHLD signal has been set to SIG_IGN with signal or sigset, or if sigaction was used together with the SA_NOCLDWAIT flag, child processes will not create zombie processes when they terminate [see exit(2)].  Also, a call to wait(2) will block until all of the calling process’s child processes and traced processes terminate, and will then return a value of −1 with errno set to ECHILD. 

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. 

Defined Types and Constants

The header file <signal.h> defines the following types:

sig_atomic_t Integral type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts. 

sigset_t Signal set, as used by sigsetops(3C). 

stack_t Stack definition, as used by sigaltstack(3C). 

<signal.h> also defines the constants used by sigprocmask(2) and sigaction(2). 

System Calls

There are several families of system calls and library functions that manage the signal facilities. 

The recommended set of system calls and functions for managing the signal facilities is the set described by IEEE Std. 1003.1-1990 (POSIX) and the System V Interface Definition. The POSIX P1003.1 interfaces include

sigaction(2)
sigemptyset(3C)
sigfillset(3C)
sigaddset(3C)
sigdelset(3C)
sigismember(3C)
sigpending(2)
sigprocmask(2)
sigsuspend(2)
kill(2)

[signal set operations are described in sigsetops(3C)]. 

POSIX P1003.4 Draft 12 specifies the following interfaces for realtime signal support:

sigqueue(2)
sigtimedwait(2)
sigwaitrt(2)

The System V Interface Definition, Third Edition, includes all the POSIX P1003.1 interfaces, extends the features of sigaction, and has added

sigaltstack(2)
sigsend(2)
sigsendset(2)

The original signal interface was through signal(2) and kill(2).  The use of signal(2), however, provided an unreliable mechanism.  It’s use is adequate for defining the disposition for terminal generated signals, but is not recommended for applications that rely heavily on signals for interprocess communication. 

The Berkeley Software Distribution, in an attempt to provide more reliable signals, introduced the following functions:

sigvec(2)
sigblock(2)
sigpause(2)
sigsetmask(2)
sigstack(2)
signal(3C)

sigvec was provided to replace signal, and a signal library function was provided for compatibility.  Additional system calls were made available to block and unblock signals and to specify an alternate signal stack.  The blocking and unblocking system calls used a signal mask to specify more than one signal at a time, but the signal mask supports at most 32 signals (fewer than the number currently supported by CX/UX and many other implementations). 

Similar features were released in System V Release 3, including these system calls and functions:

sigset(2)
sighold(2)
sigrelse(2)
sigignore(2)
sigpause(2)

[see sigset(2)].  sigset addressed the reliability concerns with the original signal system call, and the other functions provided features similar to the BSD blocking and unblocking features, but for one signal at a time instead of using a signal mask. 

All of these interfaces are supported in CX/UX.  It is recommended that applications confine themselves to using the functions within a single interface family. 

Signal Handlers

The signal handler interface conforms to the 88open Object Compatibility Standard:

handler(sig, sip)
int sig;
struct siginfo ∗sip;

Where sig is the signal number and sip is a pointer to the siginfo structure (defined in <signal.h>) used to obtain (and possibly modify) register values and to obtain a pointer to the sigframe structure (also defined in <signal.h>). 

The sf_sigsource field of the sigframe structure defines the origin of the signal as follows:

1 Signal was generated by a hardware exception (e.g.  SIGILL); all of the signals that can be generated in this manner are described in the Relationship Between Signals and Exceptions (see below). 

2 Signal was generated by the kernel (e.g.  SIGPIPE). 

3 Signal was generated by a call to kill(2) or similar function. 

Zero or more exception blocks specific to the type of signal(s) that the signal frame represents, may be pushed on the stack, immediately following the sigframe structure.  The sf_numexceptblock field in the sigframe structure specifies the number of exception blocks associated with the signal.  If there is at least one exception block for the signal, then the eb_numarg field of the first exceptblock structure will immediately follow the sf_numexceptblock field of the sigframe structure in memory.  The eb_numarg field specifies the number of arguments in the exception block.  The argument(s) immediately follow the eb_numarg field in memory. 

If sf_numexceptblock is greater than one, then additional exceptblock structures will follow the first exceptblock structure in memory. 
 
When the SA_SIGINFO flag is used [see sigaction(2)], the signal handler should have the following interface:

handler(sig, infop, ucp)
int sig;
siginfo_t ∗infop;
ucontext_t ∗ucp;

As in other interfaces, sig is the signal number.  If the second argument, infop, is not NULL, it points to a siginfo_t structure containing the reason why the signal was generated [see siginfo(5)].  The third argument, ucp, points to a ucontext_t structure containing the receiving process’s context when the signal was delivered [see ucontext(5)]. 

The program may modify the value of uc_sigmask in the context while in the signal handler and may modify general purpose and instruction address registers when handling an exception.  Note that any modification of the context should be done judiciously. 

Signals generated by the kernel will result in a positive value in the si_code field of the siginfo_t structure. 

For the SIGIO signal, when generated as a result of a completed asynchronous I/O operation, the si_value field of the siginfo_t structure contains the identifier of the operation. 

Exception blocks, defined in <sys/siginfo.h>, are constructed for signals that result from hardware exceptions.  The eb_code field (and the si_code field) contains the first argument from the table below, the eb_subcode field contains an optional second argument from the table below, and the _eb_registers union contains the optional register values as indicated by the table below [see <sys/regset.h>].  si_ncodes contains the number of exception blocks and si_exblks contains a pointer to the first exception block in the exception block array. 

Relationship Between Signals and Exceptions

As defined in the 88open Binary Compatibility Standard, the kernel will provide exception block arguments for the following exceptions when the signal source, sf_sigsource, is 1 or 2:

Exception SignalArgumentsRemarks

Code accessSIGSEGV0x01 See Note 1
 Data accessSIGSEGV0x02, See Note 2
DMA0,
DMT0,
DMD0
 Misaligned data accessSIGBUS0x01See Note 3
 Protection violationSIGBUS0x02,
DMA0,
DMT0,
DMD0
 Unimplemented opcode SIGILL0x01See Note 11
 Privileged instructionSIGILL0x02
violation
 Integer overflowSIGFPE0x8000 0001
 Integer divideSIGFPE0x8000 0002See Note 4
    or
0x8000 0001
 Bounds check trapSIGFPE0x8000 0003
 Trap on fork system callSIGTRAP−1 See fork(2)
 Trap on execve system callSIGTRAP−1 See execve(2)
 Trap to vectors 504-511SIGTRAPvector number
 Floating point inexactSIGFPE0x01,See Note 5
FPRH,
FPRL,
FPIT
 Floating point overflowSIGFPE0x02,0x01,See Note 6
FPRH,
FPRL,
FPIT
 Floating point underflowSIGFPE0x04,0x01,See Note 7
FPRH,
FPRL,
FPIT
 Floating point divideSIGFPE0x08 or 0x10See Note 8
by zero
 Floating point reservedSIGFPE 0x10 or 0x80See Note 9
operand
 Floating point integerSIGFPE 0x10See Note 10
conversion overflow
 Floating point privilegeSIGFPE0x02
violation
 Floating point SIGFPE0x40
unimplemented opcode

Notes For Exception Block Arguments

1.  Code access exceptions caused by demand paging within the text segment and areas made executable with the memctl(2) call will be handled transparently to the application. 

2.  Data access exceptions caused by references to the stack segment will be handled by extending the stack in a manner transparent to the application.  Data access exceptions caused by demand paging will be handled transparently to the application. 

3.  This exception can be disabled by setting the MXM bit of the Processor Status Register; see setpsr(2). 

4.  If the faulting instruction is DIV, the dividend is the most negative integer and the divisor is −1, then the SIGFPE signal will be sent with 0x8000 0001 as the first argument.  If the divisor is zero, the SIGFPE signal will be sent with 0x8000 0002 as the first argument.  Otherwise, the faulting instruction must be DIV and one or both operands is negative.  In this case, the system will complete the operation in a manner transparent to the application. 

5.  This exception can be disabled by clearing bit 0 (EFINX) of the Floating Point Control Register.

6.  If bit 1 (EFOVF) of the FPCR is set, the SIGFPE signal will be sent with 0x02 as the first argument.  Otherwise, bit 1 (AFOVF) of the FPSR will be set, and if bit 0 (EFINX) of the FPCR is set, the SIGFPE signal will be sent with 0x01 as the first argument.  If bit 0 of the FPCR is also clear, then bit 0 (AFINX) of the FPSR will be set and the system will complete the operation in a manner transparent to the application and consistent with ANSI/IEEE Std 754-1985 and the MC88100 User’s Manual.

7.  If bit 2 (EFUNF) of the FPCR is set, the SIGFPE signal will be sent with 0x04 as the first argument.  If there has been a loss of accuracy, bit 2 (AFUNF) of the FPSR will be set.  In this case, if bit 0 (EFINX) of the FPCR is set, the SIGFPE signal will be sent with 0x01 as the first argument; if it is clear, then bit 0 (AFINX) of the FPSR will be set.  If no signal is sent, the system will complete the operation in a manner transparent to the application and consistent with ANSI/IEEE Std 754-1985 and the MC88100 User’s Manual.

8.  If the numerator is zero, the exception will be handled as a floating point reserved operand exception.  Otherwise, if bit 3 (EFDVZ) of the FPCR is set, the SIGFPE signal will be sent with 0x08 as the first argument.  If bit 3 of the FPCR is clear, then the system will set bit 3 (AFDVZ) of the FPSR and complete the operation in a manner transparent to the application and consistent with ANSI/IEEE Std 754-1985 and the MC88100 User’s Manual.

9.  If the operation is the subtraction of two infinities, the multiplication of infinity and zero, or the division of one infinity by another, and bit 4 (EFINV) of the FPCR is set, then the SIGFPE signal will be sent with 0x10 as the first argument; otherwise bit 4 (AFINV) of the FPSR will be set.  If either operand is a signalling NaN and bit 4 of the FPCR is set, then the SIGFPE signal will be sent with 0x80 as the first argument; otherwise bit 4 of the FPSR will be set.  If no signal is sent, the system will complete the operation in a manner transparent to the application and consistent with ANSI/IEEE Std 754-1985 and the MC88100 User’s Manual.

10.  If the operand can be converted to an integer without overflow, the system will complete the operation in a manner transparent to the application.  If it cannot, and bit 4 (EFINV) of the FPCR is set, then the SIGFPE signal will be sent.  If bit 4 of the FPCR is clear, then bit 4 (AFINV) of the FPSR will be set and the system will complete the operation in a manner transparent to the application and consistent with ANSI/IEEE Std 754-1985.

11.  Conforming applications will not use unimplemented opcodes.  It is possible that some currently unimplemented opcodes may eventually be used for other functions in the future. 

NOTES

The disposition of signals that are inherited as SIG_IGN should not be changed. 

When processing a pipeline, the shell makes the last process in the pipeline the parent of the preceding 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 SIGCHLD to be caught. 

The 88open Object Compatibility Standard (OCS) defines a structure named siginfo which is passed to signal handlers.  System V Release 4 and P1003.4 use that name for a completely different structure.  The OCS structure is defined in <signal.h>, but it will not be visible if the System V Release 4 header file <sys/siginfo.h> is included in the same source module; instead, the System V Release 4 structure will have that name.  It is recommended that references to the System V Release 4 structure use the defined type siginfo_t for clarity. 

SEE ALSO

­exit(2), ­getrlimit(2), ­intro(2), ­kill(2), ­pause(2), ­sigaction(2), ­sigaltstack(2), ­signal(2), ­sigprocmask(2), ­sigqueue(2), ­sigsend(2), ­sigset(2), ­sigsuspend(2), ­sigtimedwait(2), ­wait(2), ­sigsetops(3C), ­siginfo(5), ­ucontext(5). 

CX/UX Programmer’s Reference Manual