summaryrefslogtreecommitdiff
path: root/manual
diff options
context:
space:
mode:
authorRoland McGrath <roland@gnu.org>1994-10-17 05:55:02 +0000
committerRoland McGrath <roland@gnu.org>1994-10-17 05:55:02 +0000
commitcd6d71894482bb973153cdfacdbffc309dc5394b (patch)
treeec7b8ee952a317856f589bad8f0c55c9acc7cbe4 /manual
parentb0e21aa6eff9995c04277f784f5258c9682a2947 (diff)
(Standard Signals): Update menu.
(Operation Error Signals): New node; SIGPIPE moved here from Miscellaneous Signals, SIGXCPU and SIGXFSZ from Nonstandard Signals, SIGLOST added new. (Miscellaneous Signals): Move SIGWINCH here; add SIGINFO. (Nonstandard Signals): Node removed.
Diffstat (limited to 'manual')
-rw-r--r--manual/signal.texi197
1 files changed, 119 insertions, 78 deletions
diff --git a/manual/signal.texi b/manual/signal.texi
index 7339e4c2cd..47ff92094c 100644
--- a/manual/signal.texi
+++ b/manual/signal.texi
@@ -233,8 +233,8 @@ defined. Since the signal numbers are allocated consecutively,
* Alarm Signals:: Used to indicate expiration of timers.
* Asynchronous I/O Signals:: Used to indicate input is available.
* Job Control Signals:: Signals used to support job control.
+* Operation Error Signals:: Used to report operational system errors.
* Miscellaneous Signals:: Miscellaneous Signals.
-* Nonstandard Signals:: Implementations can support other signals.
* Signal Messages:: Printing a message describing a signal.
@end menu
@@ -428,6 +428,38 @@ This signal indicates an error detected by the program itself and
reported by calling @code{abort}. @xref{Aborting a Program}.
@end deftypevr
+@comment signal.h
+@comment Unix
+@deftypevr Macro int SIGIOT
+Generated by the PDP-11 ``iot'' instruction. On most machines, this is
+just another name for @code{SIGABRT}.
+@end deftypevr
+
+@comment signal.h
+@comment BSD
+@deftypevr Macro int SIGTRAP
+Generated by the machine's breakpoint instruction, and possibly other
+trap instructions. This signal is used by debuggers. Your program will
+probably only see @code{SIGTRAP} if it is somehow executing bad
+instructions.
+@end deftypevr.
+
+@comment signal.h
+@comment BSD
+@deftypevr Macro int SIGEMT
+Emulator trap; this results from certain unimplemented instructions
+which might be emulated in software, or the operating system's
+failure to properly emulate them.
+@end deftypevr
+
+@comment signal.h
+@comment Unix
+@deftypevr Macro int SIGSYS
+Bad system call; that is to say, the instruction to trap to the
+operating system was executed, but the code number for the system call
+to perform was invalid.
+@end deftypevr
+
@node Termination Signals
@subsection Termination Signals
@cindex program termination signals
@@ -603,6 +635,13 @@ This signal is sent when ``urgent'' or out-of-band data arrives on a
socket. @xref{Out-of-Band Data}.
@end deftypevr
+@comment signal.h
+@comment SVID
+@deftypevr Macro int SIGPOLL
+This is a System V signal name, more or less similar to @code{SIGIO}.
+It is defined only for compatibility.
+@end deftypevr
+
@node Job Control Signals
@subsection Job Control Signals
@cindex job control signals
@@ -630,6 +669,12 @@ system.
@end deftypevr
@comment signal.h
+@comment SVID
+@deftypevr Macro int SIGCLD
+This is an obsolete name for @code{SIGCHLD}.
+@end deftypevr
+
+@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGCONT
@cindex continue signal
@@ -723,23 +768,26 @@ a GNU system unless you have requested POSIX compatibility ``till it
hurts.''
@end ignore
-@node Miscellaneous Signals
-@subsection Miscellaneous Signals
+@node Operation Error Signals
+@subsection Operation Error Signals
-These signals are used to report various other conditions. The default
-action for all of them is to cause the process to terminate.
+These signals are used to report various errors generated by an
+operation done by the program. They do not necessarily indicate a
+programming error in the program, but an error that prevents an
+operating system call from completing. The default action for all of
+them is to cause the process to terminate.
@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGPIPE
@cindex pipe signal
@cindex broken pipe signal
-If you use pipes or FIFOs, you have to design your application so that
-one process opens the pipe for reading before another starts writing.
-If the reading process never starts, or terminates unexpectedly, writing
-to the pipe or FIFO raises a @code{SIGPIPE} signal. If @code{SIGPIPE}
-is blocked, handled or ignored, the offending call fails with
-@code{EPIPE} instead.
+Broken pipe. If you use pipes or FIFOs, you have to design your
+application so that one process opens the pipe for reading before
+another starts writing. If the reading process never starts, or
+terminates unexpectedly, writing to the pipe or FIFO raises a
+@code{SIGPIPE} signal. If @code{SIGPIPE} is blocked, handled or
+ignored, the offending call fails with @code{EPIPE} instead.
Pipes and FIFO special files are discussed in more detail in @ref{Pipes
and FIFOs}.
@@ -748,7 +796,37 @@ Another cause of @code{SIGPIPE} is when you try to output to a socket
that isn't connected. @xref{Sending Data}.
@end deftypevr
-@need 245
+@comment signal.h
+@comment GNU
+@deftypevr Macro int SIGLOST
+@cindex lost resource signal
+Resource lost. This signal is generated when you have an advisory lock
+on an NFS file, and the NFS server reboots and forgets about your lock.
+
+In the GNU system, @code{SIGLOST} is generated when any server program
+dies unexpectedly. It is usually fine to ignore the signal; whatever
+call was made to the server that died just returns an error.
+@end deftypevr
+
+@comment signal.h
+@comment BSD
+@deftypevr Macro int SIGXCPU
+CPU time limit exceeded. This signal is generated when the process
+exceeds its soft resource limit on CPU time. @xref{Resource Limits}.
+@end deftypevr
+
+@item SIGXFSZ
+File size limit exceeded. This signal is generated when the process
+attempts to extend a file so it exceeds the process's soft resource
+limit on file size. @xref{Resource Limits}.
+@end deftypevr
+
+@node Miscellaneous Signals
+@subsection Miscellaneous Signals
+
+These signals are used for various other purposes. In general, they
+will not affect your program unless it explicitly uses them for something.
+
@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGUSR1
@@ -756,79 +834,42 @@ that isn't connected. @xref{Sending Data}.
@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGUSR2
+@cindex user signals
The @code{SIGUSR1} and @code{SIGUSR2} signals are set aside for you to
-use any way you want. They're useful for interprocess communication.
-Since these signals are normally fatal, you should write a signal handler
-for them in the program that receives the signal.
+use any way you want. They're useful for simple interprocess
+communication, if you write a signal handler for them in the program
+that receives the signal.
There is an example showing the use of @code{SIGUSR1} and @code{SIGUSR2}
in @ref{Signaling Another Process}.
-@end deftypevr
-@cindex user signals
-
-@node Nonstandard Signals
-@subsection Nonstandard Signals
-
-Particular operating systems support additional signals not listed
-above. The ANSI C standard reserves all identifiers beginning with
-@samp{SIG} followed by an uppercase letter for the names of signals.
-You should consult the documentation or header files for your particular
-operating system and processor type to find out about the specific
-signals it supports.
-
-For example, some systems support extra signals which correspond to
-hardware traps. Some other kinds of signals commonly supported are used
-to implement limits on CPU time or file system usage, asynchronous
-changes to terminal configuration, and the like. Systems may also
-define signal names that are aliases for standard signal names.
-
-You can generally assume that the default action (or the action set up
-by the shell) for implementation-defined signals is reasonable, and not
-worry about them yourself. In fact, it's usually a bad idea to ignore
-or block signals you don't know anything about, or try to establish a
-handler for signals whose meanings you don't know.
-
-Here are some of the other signals found on commonly used operating
-systems:
-
-@table @code
-@item SIGCLD
-Obsolete name for @code{SIGCHLD}.
-
-@item SIGTRAP
-Generated by the machine's breakpoint instruction. Used by debuggers.
-Default action is to dump core.
-
-@item SIGIOT
-Generated by the PDP-11 ``iot'' instruction; equivalent to @code{SIGABRT}.
-Default action is to dump core.
-@item SIGEMT
-Emulator trap; this results from certain unimplemented instructions
-which might be emulated in software. It is a program error signal.
-
-@item SIGSYS
-Bad system call; that is to say, the instruction to trap to the
-operating system was executed, but the code number for the system call
-to perform was invalid. This is a program error signal.
-
-@item SIGPOLL
-This is a System V signal name, more or less similar to @code{SIGIO}.
-
-@item SIGXCPU
-CPU time limit exceeded. This is used for batch processing.
-Default action is program termination.
-
-@item SIGXFSZ
-File size limit exceeded. This is used for batch processing.
-Default action is program termination.
+The default action is to terminate the process.
+@end deftypevr
-@item SIGWINCH
-Window size change. This is generated on certain systems when the size
-of the current window on the screen is changed. Default action is to
-ignore it.
-@end table
+@comment signal.h
+@comment BSD
+@deftypevr Macro int SIGWINCH
+Window size change. This is generated on some systems (including GNU)
+when the terminal driver's record of the number of rows and columns on
+the screen is changed. The default action is to ignore it.
+
+If a program does full-screen display, it should handle @code{SIGWINCH}.
+When the signal arrives, it should fetch the new screen size and
+reformat its display accordingly.
+@end deftypevr
+@comment signal.h
+@comment BSD
+@deftypevr Macro int SIGINFO
+Information request. In 4.4 BSD and the GNU system, this signal is sent
+to all the processes in the foreground process group of the controlling
+terminal when the user types the STATUS character in canonical mode;
+@pxref{Characters that Cause Signals}.
+
+If the process is the leader of the process group, the default action is
+to print some status information about the system and what the process
+is doing. Otherwise the default is to do nothing.
+@end deftypevr
@node Signal Messages
@subsection Signal Messages