NAME

sigsys − catch or ignore signals

SYNOPSIS

#include <signal.h>

(*sigsys(sig, func))()
void (*func)();

DESCRIPTION

N.B.: The system currently supports two signal implementations. The one described in signal(2) is standard in version 7 UNIX systems, and retained for backward compatibility as it is different in a number of ways. The one described here (with the interface in sigset(3)) provides for the needs of the job control mechanisms (see jobs(3)) used by csh(1), and corrects the bugs in the standard implementation of signals, allowing programs which process interrupts to be written reliably.

The routine sigsys is not normally called directly; rather the routines of sigset(3) should be used. These routines are located in the global library/lib/clib, and thus do not have to be bound with a loader option.  The features described here are less portable then those of signal(2) and should not be used in programs which are to be moved to other versions of UNIX.

A signal is generated by some abnormal event, initiated by a user at a terminal (quit, interrupt, stop), by a program error (bus error, etc.), or by request of another program (kill).  Signals are optionally generated when a process resumes after being stopped, when the status of child processes changes, or when input is ready at the control terminal.  Most signals cause termination of the receiving process if no action is taken; some signals instead cause the process receiving them to be stopped, or are simply discarded if the process has not requested otherwise.  Except for the SIGKILL and SIGSTOP signals which cannot be blocked, the sigsys call allows signals either to be ignored, held until a later time (protecting critical sections in the process), or to cause an interrupt to a specified location.  Here is the list of all signals with names as in the include file. 

SIGHUP1hangup
SIGINT2interrupt (rubout)
SIGQUIT3quit (ASCII FS)
SIGILL4illegal instruction (not reset when caught)
SIGTRAP5trace trap (not reset when caught)
SIGIOT6IOT instruction
SIGEMT7EMT instruction
SIGFPE8floating point exception
SIGKILL9kill (cannot be caught or ignored)
SIGBUS10bus error
SIGSEGV11segmentation violation
SIGSYS12bad argument to system call
SIGPIPE13write on a pipe with no one to read it
SIGALRM14alarm clock
SIGTERM15software termination signal from kill
SIGUSR116user defined signal 1
SIGUSR217user defined signal 2
SIGCLD18death of a child
SIGPWR19power-fail restart
SIGSTOP20†stop, cannot be caught, held, or ignored
SIGTSTP21†stop signal generated from keyboard
SIGCONT22•continue after stop
SIGCHLD23•child status has changed
SIGTTIN24†background read attempted from control terminal
SIGTTOU25†background write attempted to control terminal
SIGTINT26input record is available at control terminal
SIGXCPU27cpu time limit exceeded
SIGXFSZ28file size limit exceeded

If func is SIG_DFL, the default action for signal sig is reinstated; this default is termination. 

Signals marked with • are discarded if the action is SIG_DFL; signals marked with † cause the process to stop. 

If func is SIG_HOLD the signal is remembered if it occurs, but not presented to the process; it may be presented later if the process changes the action for the signal.  If func is SIG_IGN the signal is subsequently ignored, and pending instances of the signal are discarded (i.e. if the action was previously SIG_HOLD.)  Otherwise when the signal occurs func will be called. 

A return from the function will continue the process at the point it was interrupted.  Except as indicated, a signal, set with sigsys, is reset to SIG_DFL after being caught.  However by specifying DEFERSIG(func) as the last argument to sigsys, one causes the action to be set to SIG_HOLD before the interrupt is taken, so that recursive instances of the signal cannot occur during handling of the signal. 

When a caught signal occurs during certain system calls, the call terminates prematurely.  In particular this can occur during a read or write(2) on a slow device (like a terminal; but not a file) and during a pause or wait(2). When a signal occurs during one of these calls, the saved user status is arranged in such a way that, when return from the signal-catching takes place, it will appear that the system call returned an error status. The user’s program may then, if it wishes, re-execute the call. Read and write calls which have done no I/O, ioctls blocked with SIGTTOU, and wait3 calls are restarted. 

The value of sigsys is the previous (or initial) value of func for the particular signal. 

The system provides two other functions by oring bits into the signal number: SIGDOPAUSE causes the process to pause after changing the signal action.  It can be used to atomically re-enable a held signal which was being processed and wait for another instance of the signal.  SIGDORTI causes the system to simulate an rei instruction clearing the mark the system placed on the stack at the point of interrupt before checking for further signals to be presented due to the specified change in signal actions.  This allows a signal package such as sigset(3) to dismiss from interrupts cleanly removing the old state from the stack before another instance of the interrupt is presented.

After a fork(2) or vfork(2) the child inherits all signals. Exec(2) resets all caught signals to default action; held signals remain held and ignored signals remain ignored.

SEE ALSO

kill(1), kill(2), jobs(3), sigset(3), setjmp(3)

DIAGNOSTICS

The value BADSIG (-1) is returned if the given signal is out of range. 

BUGS

The job control facilities are not available in standard version 7 UNIX.  These facilities are still under development and may change in future releases of the system as better inter-process communication facilities and support for virtual terminals become available.  The options and specifications of this facility and the system calls supporting it are thus subject to change. 

Since only one signal action can be changed at a time, it is not possible to get the effect of SIGDOPAUSE for more than one signal at a time.