BSD 4_1c_2 development
authorCSRG <csrg@ucbvax.Berkeley.EDU>
Fri, 4 Mar 1983 13:27:18 +0000 (05:27 -0800)
committerCSRG <csrg@ucbvax.Berkeley.EDU>
Fri, 4 Mar 1983 13:27:18 +0000 (05:27 -0800)
Work on file usr/man/man2/signal.2

Synthesized-from: CSRG/cd1/4.1c.2

usr/man/man2/signal.2 [new file with mode: 0644]

diff --git a/usr/man/man2/signal.2 b/usr/man/man2/signal.2
new file mode 100644 (file)
index 0000000..7d6815c
--- /dev/null
@@ -0,0 +1,192 @@
+.TH SIGNAL 2 2/12/83
+.SH NAME
+signal \- catch or ignore signals
+.SH SYNOPSIS
+.nf
+.ft B
+#include <signal.h>
+.PP
+.ft B
+int (*signal(sig, func))()
+int sig;
+int (*func)();
+.fi
+.ft R
+.SH DESCRIPTION
+\fBThis interface is obsolete and will be replaced in the 4.2 release
+by an interface compatible with signal(3J) and sigsys(2).\fP
+.PP
+.I Signal
+allows the calling process to choose how it will handle
+the receipt of a specific signal.
+.I Sig
+specifies the signal and
+.I func
+specifies the choice.
+.PP
+A signal
+is generated by some abnormal event,
+initiated either by user at a terminal (quit, interrupt),
+by a program error (bus error, etc.),
+or by request of another program (kill).
+Normally all signals
+cause termination of the receiving process,
+but a
+.I signal
+call allows them either to be ignored
+or to cause an interrupt to a specified location.
+Here is the list of signals with names as in
+the include file.
+.LP
+.nf
+.ta \w'SIGVTALRM 'u +\w'15*  'u
+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 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
+SIGURG 16      urgent condition pending
+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 (see \fIsetdopts\fP(2))
+SIGXCPU        24      cpu time limit exceeded (see \fIsetrlimit\fP(2))
+SIGXFSZ        25      file size limit exceeded (see \fIsetrlimit\fP(2))
+SIGVTALRM      26      virtual time alarm (see \fIsetitimer\fP(2))
+SIGPROF        27      profiling timer alarm (see \fIsetitimer\fP(2))
+.fi
+.PP
+Signal numbers 1, 2, 4, and 9 may be referred to by
+their absolute decimal values.  All other signals should be
+referred to symbolically.
+.PP
+The starred signals in the list above cause a core image
+if not caught or ignored.
+.PP
+If
+.I func
+is SIG_DFL, the default action
+for signal
+.I sig
+is reinstated; this default is termination,
+sometimes with a core image.
+If
+.I func
+is SIG_IGN the signal is ignored.
+Otherwise
+when the signal occurs
+.I func
+will be called with the
+signal number as argument.
+A return from the function will
+continue the process at the point it was interrupted.
+.PP
+Except as indicated,
+a signal is reset to SIG_DFL after being caught.
+Thus if it is desired to
+catch every such signal,
+the catching routine must
+issue another
+.I signal
+call.
+.PP
+If, when using this (older) signal interface,
+a caught signal occurs
+during certain system calls, the call terminates prematurely.
+In particular this can occur
+during an
+.IR ioctl ,
+.IR read ,
+or
+.IR write (2)
+on a slow device (like a terminal; but not a file);
+and during
+.I pause
+or
+.IR wait (2).
+When such a signal occurs, 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 EINTR.
+The user's program may then, if it wishes,
+re-execute the call.
+.PP
+The value of
+.I signal
+is the previous (or initial)
+value of
+.I func
+for the particular signal.
+.PP
+After a
+.IR  fork (2)
+the child inherits
+all signals.
+.IR  Exec (2)
+resets all
+caught signals to default action.
+.SH "RETURN VALUE
+Upon successful completion,
+.I signal
+returns the previous value of
+.I func
+for the specified signal
+.IR sig .
+Otherwise, a value of \-1
+is returned and
+.I errno
+is set to indicate the error.
+.SH ERRORS
+.I Signal
+will fail if one or more of the following are true:
+.TP 15
+[EINVAL]
+\fISig\fP is an illegal signal number,
+including SIGKILL.
+.TP 15
+[EFAULT]
+\fIFunc\fP points to an illegal address.
+.SH CAVEATS
+The
+.I signal
+function is not recommended for use as an interprocess
+communications mechanism.
+.SH "SEE ALSO"
+kill(2),
+pause(2),
+sigsys(2),
+signal(3),
+psignal(3)
+.SH DIAGNOSTICS
+The value (int)\-1 is returned if the
+given signal is out of range.
+.SH BUGS
+The traps should be distinguishable by extra arguments
+to the signal handler, and all hardware supplied parameters should
+be made available to the signal routine.
+.PP
+If a repeated signal arrives before the last one can be
+reset, there is no chance to catch it
+(however this is
+.B not
+true if you use
+.IR sigsys (2J)
+and
+.IR sigset (3)).
+.PP
+The type specification of the routine and its
+.I func
+argument are problematical.