diff options
author | Roland McGrath <roland@gnu.org> | 1994-10-17 05:55:02 +0000 |
---|---|---|
committer | Roland McGrath <roland@gnu.org> | 1994-10-17 05:55:02 +0000 |
commit | cd6d71894482bb973153cdfacdbffc309dc5394b (patch) | |
tree | ec7b8ee952a317856f589bad8f0c55c9acc7cbe4 /manual | |
parent | b0e21aa6eff9995c04277f784f5258c9682a2947 (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.texi | 197 |
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 |