⟦65c20eb1b⟧

TextFile

.ig
	@(#)sigsys.2j	2.1	7/1/84
	@(#)Copyright (C) 1983 by National Semiconductor Corp.
..
.TH SIGSYS 2J
.ie t .ds d \(dg
.el .ds d \z'|+'
.ie t .ds b \(bu
.el .ds b @
.SH NAME
sigsys \- catch or ignore signals
.SH SYNOPSIS
.nf
.B #include <signal.h>
.PP
.B (*sigsys(sig, func))()
.B void (*func)();
.PP
.B cc ... \-ljobs
.fi
.SH DESCRIPTION
.IR N.B. :
The system currently supports two signal implementations.
The one described in
.IR 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
.IR sigset (3))
provides for the needs of the job control mechanisms (see
.IR jobs (3))
used by
.IR csh (1),
and corrects the bugs in the standard implementation of signals,
allowing programs which process interrupts to be written reliably.
.PP
The routine
.I sigsys
is not normally called directly; rather the routines of
.IR sigset (3)
should be used.
These routines are kept in the ``jobs'' library, accessible by
giving the loader option
.BR \-ljobs .
The features described here are less portable then those of
.IR signal (2)
and should not be used in programs which are
to be moved to other versions of UNIX.
.PP
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.),
by request of another program (kill),
or when a process is stopped because it wishes to access
its control terminal while in the background (see
.IR 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 instead cause the process receiving them
to be stopped, or are simply discarded if the process has not
requested otherwise.
Except for SIGKILL and SIGSTOP,
which cannot be blocked, the
.I 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 specified in the file
.IR /usr/include/signal.h :
.LP
.nf
.ta \w'SIGMMMM 'u +\w'15*  'u
SIGHUP	\01	hangup
SIGINT	\02	interrupt
SIGQUIT	\03*	quit
SIGILL	\04*	illegal instruction (not reset when caught)
SIGTRAP	\05*	trace trap (not reset when caught)
SIGIOT	\06*	IOT instruction
SIGEMT	\07*	EMT instruction
SIGFPE	\08*	floating point exception
SIGKILL	\09	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 a pipe with no one to read it
SIGALRM	14	alarm clock
SIGTERM	15	software termination signal
	16	unassigned
SIGSTOP	17\*d	stop (cannot be caught, held or ignored)
SIGTSTP	18\*d	stop signal generated from keyboard
SIGCONT	19\*b	continue after stop
SIGCHLD	20\*b	child status has changed
SIGTTIN	21\*d	background read attempted from control terminal
SIGTTOU	22\*d	background write attempted to control terminal
SIGTINT	23\*b	input record is available at control terminal
SIGXCPU	24	cpu time limit exceeded (see \f2vlimit\fP(2))
SIGXFSZ	25	file size limit exceeded (see \f2vlimit\fP(2))
SIGDVZ	26*	integer divide by zero
SIGNMI	27	MMU debugging interrupt
SIGBPT	28	breakpoint instruction
SIGPROF	29\*b	profiling interrupt (temporary implementation)
.fi
.DT
.PP
The starred signals in the list above cause a core image
if not caught,
held,
or ignored.
.PP
If
.I func
is SIG_DFL,
the default action for signal
.I sig
is reinstated;
this default is termination
(with a core image for starred signals)
except for signals marked with \*b or \*d.
Signals marked with \*b are discarded if the action is SIG_DFL;
signals marked with \*d cause the process to stop.
If
.I func
is SIG_HOLD,
the signal is remembered if it occurs,
but is not presented to the process;
it may be presented later if the process changes the action for the signal.
If
.I 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,
.I func
will be called.
.PP
A return from the function will
continue the process at the point it was interrupted.
Except as indicated,
a signal, set with
.I sigsys,
is reset to SIG_DFL after being caught.  However by
specifying DEFERSIG(func) as the last argument to
.I 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.
.PP
When a caught signal occurs
during certain system calls, the call terminates prematurely.
In particular this can occur
during a
.IR read (2)
or
.IR write (2)
on a slow device (such as a terminal, but not a file)
and during a
.IR pause (2)
or
.IR 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 routine 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.
.I Read
and
.I write
calls that have done no I/O,
.IR ioctl (2)
calls blocked with SIGTTOU,
and
.IR wait3 (2J)
calls are restarted.
.PP
The value of
.I sigsys
is the previous (or initial)
value of
.I func
for the particular signal.
.PP
The system provides two other functions by or-ing bits into the
signal number:
SIGDOPAUSE causes the process to
.I pause
after changing the signal action.
It can be used to atomically re-enable a held signal
that was being processed and wait for
another instance of the signal.
SIGDORTI causes the system to simulate a
.I rett
instruction,
which clears 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
.IR sigset (3)
to dismiss from interrupts cleanly removing the old state from
the stack before another instance of the interrupt is presented.
.PP
After a
.IR fork (2)
or
.IR vfork (2)
the child inherits
all signals.
.IR Exec (2)
resets all
caught signals to default action; held signals remain held
and ignored signals remain ignored.
.SH "SEE ALSO"
kill(1),
ptrace(2),
kill(2),
jobs(3),
sigset(3),
setjmp(3),
tty(4)
.SH DIAGNOSTICS
The value BADSIG is returned if the
given signal is out of range.
.SH 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 the job control facilities and the 
supporting system calls are thus subject to change.
.PP
Because 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.
.SH "NOTES (\fISeries 32000\fP)"
If
.I func
is 0 (SIG_DFL),
the default action is reinstated.
If
.I func
is 1 (SIG_IGN),
the signal is ignored.
If
.I func
is 3 (SIG_HOLD),
the signal is held.
Any other
.I func
specifies an address in the process
where an interrupt is simulated.
If the high bit of func is one, the signal is sent to the function
whose address is func with the high bit cleared
with the action set to SIG_HOLD.
(Thus DEFERSIG is indicated by the high bit of a signal catch address.)
.PP
The handler routine can be declared:
.PP
    handler(signo)
.PP
Here
.I signo
is the signal name.
.PP
When a signal occurs,
the kernel does not call the specified signal handler directly.
Instead,
the special routine
.IR sigentry (3)
is called, as described in
.IR signal (2).
However,
the version of
.I sigentry
used with
.I sigsys
is more complicated than the normal one,
and must save more state.
DataMuseum.dk

ICL Comet 32

⟦65c20eb1b⟧ TextFile

Derivation

TextFile
