Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ sigsys(2j) — Ultrix-11 3.1

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

kill(1)

kill(2)

ptrace(2)

intro(3j)

setjmp(3)

sigset(3j)

tty(4)

sigsys(2j)

NAME

sigsys − catch or ignore signals

SYNTAX

#include <signal.h>

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

cc ... −ljobs

DESCRIPTION

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

The sigsys system call is not normally called directly.  Rather, the routines of sigset(3j) should be used.  These routines are kept in the “jobs” library which is accessible by giving the loader the following option:

−ljobs.

The features described here are less portable than those of the signal call 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 that is initiated by a user at a terminal (for example, a quit or interrupt), by a program error (for example, a bus error), by request of another program (for example, a kill command), or when a process is stopped because it wishes to access its control terminal while in the background.  For further information about terminal access, see tty(4). 

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, however, 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, to be held until a later time (protecting critical sections in the process), or to cause an interrupt to a specified location.  The following lists all signals with their names as in the include file:

SIGHUP      1     Hangup
SIGINT      2     Interrupt
SIGQUIT     3*    Quit
SIGILL      4*    Illegal instruction (not reset when caught)
SIGTRAP     5*    Trace trap (not reset when caught)
SIGIOT      6*    IOT instruction
SIGEMT      7*    EMT instruction
SIGFPE      8*    Floating point exception
SIGKILL     9     Kill (cannot be caught, held or ignored)
SIGBUS     10*    Bus error
SIGSEGV    11*    Segmentation violation
SIGSYS     12*    Bad argument to system call
SIGPIPE    13     Write on pipe with no one to read
SIGALRM    14     Alarm clock
SIGTERM    15     Software termination signal
SIGURG     16•  Urgent condition is present on socket
SIGSTOP    17†  Stop (cannot be caught, held or ignored)
SIGTSTP    18†  Stop signal generated from keyboard
SIGCONT    19•  Continue after stop
SIGCHLD    20•  Child status has changed
SIGTTIN    21†  Background read attempted from control terminal
SIGTTOU    22†  Background write attempted to control terminal
SIGIO      23•  I/O is possible on a descriptor
SIGXCPU    24     CPU time limit exceeded
SIGXFSZ    25     File size limit exceeded
SIGVTALRM  26     Virtual time alarm
SIGPROF    27     Profiling timer alarm

The starred signals (*) above cause a core image if not caught, held or ignored. 

If func is SIG_DFL, the default action for signal sig is reinstated.  This default is termination (with a core image for starred signals), except for signals marked with • or †.  Signals marked with • are discarded if the action is SIG_DFL, while signals marked with † cause the process to stop.  If func is SIG_HOLD the signal is remembered if it occurs, but it is not presented to the process.  If the process changes the action for the signal, it may be presented later.  If func is SIG_IGN the signal is subsequently ignored, and pending instances of the signal are discarded (that is, 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 the sigsys call, 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 either during a read or write call on a slow device (like a terminal but not a file), or during a pause or wait call.  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.  The read and write calls which have done no I/O, ioctl calls blocked with SIGTTOU, and wait2 or wait3 calls are restarted. 

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

The system provides two other functions by a bitwise or of 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(3j), to dismiss from interrupts cleanly removing the old state from the stack before another instance of the interrupt is presented. 

After a fork or vfork call, the child inherits all signals.  An exec call resets all caught signals to default action.  The signals remain held, and the ignored signals remain ignored. 

RESTRICTIONS

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. 

The traps (listed below) should be distinguishable by extra arguments to the signal handler, and all hardware supplied parameters should be made available to the signal routine. 

RETURN VALUE

The value BADSIG is returned if the given signal is out of range. 

DIAGNOSTICS

The sigsys call will fail if:

[EINVAL] The specified sig is an illegal signal number, including SIGKILL and SIGSTOP. 

ASSEMBLER (PDP-11)

(signal = 48.) 
sys signal; sig; label
(old label in r0)

If label is 0, default action is reinstated.  If label is 1, the signal is ignored.  If label is 3, the signal is held.  Any other even label specifies an address in the process where an interrupt is simulated.  If label is otherwise odd, the signal is sent to the function whose address is the label with the low bit cleared with the action set to SIG_HOLD.  (Thus DEFERSIG is indicated by the low bit of a signal catch address.  An RTI or RTT instruction will return from the interrupt.) 

SEE ALSO

kill(1), kill(2), ptrace(2), intro(3j), setjmp(3), sigset(3j), tty(4)

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026