library_21.html

Linux程序员的工作手册

stopped.  For example, programs that turn off echoing should handle
<CODE>SIGTSTP</CODE> so they can turn echoing back on before stopping.
<P>
This signal is generated when the user types the SUSP character
(normally <KBD>C-z</KBD>).  For more information about terminal driver
support, see section <A HREF="library_16.html#SEC281" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_16.html#SEC281">Special Characters</A>.
<A NAME="IDX1518"></A>
<P>
<A NAME="IDX1519"></A>
<U>Macro:</U> int <B>SIGTTIN</B><P>
A process cannot read from the the user's terminal while it is running 
as a background job.  When any process in a background job tries to
read from the terminal, all of the processes in the job are sent a
<CODE>SIGTTIN</CODE> signal.  The default action for this signal is to
stop the process.  For more information about how this interacts with
the terminal driver, see section <A HREF="library_24.html#SEC415" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_24.html#SEC415">Access to the Controlling Terminal</A>.
<A NAME="IDX1520"></A>
<P>
<A NAME="IDX1521"></A>
<U>Macro:</U> int <B>SIGTTOU</B><P>
This is similar to <CODE>SIGTTIN</CODE>, but is generated when a process in a
background job attempts to write to the terminal or set its modes.
Again, the default action is to stop the process.
<A NAME="IDX1522"></A>
<P>
While a process is stopped, no more signals can be delivered to it until
it is continued, except <CODE>SIGKILL</CODE> signals and (obviously)
<CODE>SIGCONT</CODE> signals.  The <CODE>SIGKILL</CODE> signal always causes
termination of the process and can't be blocked or ignored.  You can
block or ignore <CODE>SIGCONT</CODE>, but it always causes the process to
be continued anyway if it is stopped.  Sending a <CODE>SIGCONT</CODE> signal
to a process causes any pending stop signals for that process to be
discarded.  Likewise, any pending <CODE>SIGCONT</CODE> signals for a process
are discarded when it receives a stop signal.
<P>
When a process in an orphaned process group (see section <A HREF="library_24.html#SEC416" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_24.html#SEC416">Orphaned Process Groups</A>) receives a <CODE>SIGTSTP</CODE>, <CODE>SIGTTIN</CODE>, or <CODE>SIGTTOU</CODE>
signal and does not handle it, the process does not stop.  Stopping the
process would be unreasonable since there would be no way to continue
it.  What happens instead depends on the operating system you are
using.  Some systems may do nothing; others may deliver another signal
instead, such as <CODE>SIGKILL</CODE> or <CODE>SIGHUP</CODE>.
<P>
<H3><A NAME="SEC341" HREF="library_toc.html#SEC341" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC341">Miscellaneous Signals</A></H3>
<P>
These signals are used to report various other conditions.  The default
action for all of them is to cause the process to terminate.
<P>
<A NAME="IDX1523"></A>
<A NAME="IDX1524"></A>
<A NAME="IDX1525"></A>
<U>Macro:</U> int <B>SIGPIPE</B><P>
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</CODE> signal.  If <CODE>SIGPIPE</CODE>
is blocked, handled or ignored, the offending call fails with
<CODE>EPIPE</CODE> instead.
<P>
Pipes and FIFO special files are discussed in more detail in section <A HREF="library_14.html#SEC211" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_14.html#SEC211">Pipes and FIFOs</A>.
<P>
Another cause of <CODE>SIGPIPE</CODE> is when you try to output to a socket
that isn't connected.  See section <A HREF="library_15.html#SEC250" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_15.html#SEC250">Sending Data</A>.
<P>
<A NAME="IDX1526"></A>
<U>Macro:</U> int <B>SIGUSR1</B><P>
<P>
<A NAME="IDX1527"></A>
<U>Macro:</U> int <B>SIGUSR2</B><P>
The <CODE>SIGUSR1</CODE> and <CODE>SIGUSR2</CODE> 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.
<P>
There is an example showing the use of <CODE>SIGUSR1</CODE> and <CODE>SIGUSR2</CODE>
in section <A HREF="library_21.html#SEC365" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC365">Signaling Another Process</A>.
<A NAME="IDX1528"></A>
<P>
<H3><A NAME="SEC342" HREF="library_toc.html#SEC342" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC342">Nonstandard Signals</A></H3>
<P>
Particular operating systems support additional signals not listed
above.  The ANSI C standard reserves all identifiers beginning with
<SAMP>`SIG'</SAMP> 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.
<P>
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.
<P>
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.
<P>
Here are some of the other signals found on commonly used operating
systems:
<P>
<DL COMPACT>
<DT><CODE>SIGCLD</CODE>
<DD>Obsolete name for <CODE>SIGCHLD</CODE>.
<P>
<DT><CODE>SIGTRAP</CODE>
<DD>Generated by the machine's breakpoint instruction.  Used by debuggers.
Default action is to dump core.
<P>
<DT><CODE>SIGIOT</CODE>
<DD>Generated by the PDP-11 "iot" instruction; equivalent to <CODE>SIGABRT</CODE>.
Default action is to dump core.
<P>
<DT><CODE>SIGEMT</CODE>
<DD>Emulator trap; this results from certain unimplemented instructions.
It is a program error signal.
<P>
<DT><CODE>SIGSYS</CODE>
<DD>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.
<P>
<DT><CODE>SIGPOLL</CODE>
<DD>This is a System V signal name, more or less similar to <CODE>SIGIO</CODE>.
<P>
<DT><CODE>SIGXCPU</CODE>
<DD>CPU time limit exceeded.  This is used for batch processing.
Default action is program termination.
<P>
<DT><CODE>SIGXFSZ</CODE>
<DD>File size limit exceeded.  This is used for batch processing.
Default action is program termination.
<P>
<DT><CODE>SIGWINCH</CODE>
<DD>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.
</DL>
<P>
<A NAME="IDX1529"></A>
<H3><A NAME="SEC343" HREF="library_toc.html#SEC343" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC343">Signal Messages</A></H3>
<P>
We mentioned above that the shell prints a message describing the signal
that terminated a child process.  The clean way to print a message
describing a signal is to use the functions <CODE>strsignal</CODE> and
<CODE>psignal</CODE>.  These functions use a signal number to specify which
kind of signal to describe.  The signal number may come from the
termination status of a child process (see section <A HREF="library_23.html#SEC407" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_23.html#SEC407">Process Completion</A>) or it
may come from a signal handler in the same process.
<P>
<A NAME="IDX1530"></A>
<U>Function:</U> char * <B>strsignal</B> <I>(int <VAR>signum</VAR>)</I><P>
This function returns a pointer to a statically-allocated string
containing a message describing the signal <VAR>signum</VAR>.  You
should not modify the contents of this string; and, since it can be
rewritten on subsequent calls, you should save a copy of it if you need
to reference it later.
<A NAME="IDX1531"></A>
<P>
This function is a GNU extension, declared in the header file
<TT>`string.h'</TT>.
<P>
<A NAME="IDX1532"></A>
<U>Function:</U> void <B>psignal</B> <I>(int <VAR>signum</VAR>, const char *<VAR>message</VAR>)</I><P>
This function prints a message describing the signal <VAR>signum</VAR> to the
standard error output stream <CODE>stderr</CODE>; see section <A HREF="library_11.html#SEC119" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_11.html#SEC119">Standard Streams</A>.
<P>
If you call <CODE>psignal</CODE> with a <VAR>message</VAR> that is either a null
pointer or an empty string, <CODE>psignal</CODE> just prints the message 
corresponding to <VAR>signum</VAR>, adding a trailing newline.
<P>
If you supply a non-null <VAR>message</VAR> argument, then <CODE>psignal</CODE>
prefixes its output with this string.  It adds a colon and a space 
character to separate the <VAR>message</VAR> from the string corresponding
to <VAR>signum</VAR>.
<A NAME="IDX1533"></A>
<P>
This function is a BSD feature, declared in the header file <TT>`stdio.h'</TT>.
<P>
<A NAME="IDX1534"></A>
<P>
There is also an array <CODE>sys_siglist</CODE> which contains the messages
for the various signal codes.  This array exists on BSD systems, unlike
<CODE>strsignal</CODE>.
<P>
<A NAME="IDX1535"></A>
<A NAME="IDX1536"></A>
<H2><A NAME="SEC344" HREF="library_toc.html#SEC344" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC344">Specifying Signal Actions</A></H2>
<P>
The simplest way to change the action for a signal is to use the
<CODE>signal</CODE> function.  You can specify a built-in action (such as to
ignore the signal), or you can <DFN>establish a handler</DFN>.
<P>
The GNU library also implements the more versatile <CODE>sigaction</CODE>
facility.  This section describes both facilities and gives suggestions
on which to use when.
<P>
<A NAME="IDX1537"></A>
<H3><A NAME="SEC345" HREF="library_toc.html#SEC345" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC345">Basic Signal Handling</A></H3>
<P>
The <CODE>signal</CODE> function provides a simple interface for establishing
an action for a particular signal.  The function and associated macros
are declared in the header file <TT>`signal.h'</TT>.
<A NAME="IDX1538"></A>
<P>
<A NAME="IDX1539"></A>
<U>Data Type:</U> <B>sighandler_t</B><P>
This is the type of signal handler functions.  Signal handlers take one
integer argument specifying the signal number, and have return type
<CODE>void</CODE>.  So, you should define handler functions like this:
<P>
<PRE>
void <VAR>handler</VAR> (int <CODE>signum</CODE>) { ... }
</PRE>
<P>
The name <CODE>sighandler_t</CODE> for this data type is a GNU extension.
<P>
<A NAME="IDX1540"></A>
<U>Function:</U> sighandler_t <B>signal</B> <I>(int <VAR>signum</VAR>, sighandler_t <VAR>action</VAR>)</I><P>
The <CODE>signal</CODE> function establishes <VAR>action</VAR> as the action for
the signal <VAR>signum</VAR>.
<P>
The first argument, <VAR>signum</VAR>, identifies the signal whose behavior
you want to control, and should be a signal number.  The proper way to
specify a signal number is with one of the symbolic signal names
described in section <A HREF="library_21.html#SEC335" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC335">Standard Signals</A>---don't use an explicit number, because
the numerical code for a given kind of signal may vary from operating
system to operating system.
<P>
The second argument, <VAR>action</VAR>, specifies the action to use for the
signal <VAR>signum</VAR>.  This can be one of the following:
<P>
<DL COMPACT>
<A NAME="IDX1541"></A>
<A NAME="IDX1542"></A>
<DT><CODE>SIG_DFL</CODE>
<DD><CODE>SIG_DFL</CODE> specifies the default action for the particular signal.
The default actions for various kinds of signals are stated in
section <A HREF="library_21.html#SEC335" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC335">Standard Signals</A>.
<P>
<A NAME="IDX1543"></A>
<A NAME="IDX1544"></A>
<DT><CODE>SIG_IGN</CODE>
<DD><CODE>SIG_IGN</CODE> specifies that the signal should be ignored.
<P>
Your program generally should not ignore signals that represent serious
events or that are normally used to request termination.  You cannot
ignore the <CODE>SIGKILL</CODE> or <CODE>SIGSTOP</CODE> signals at all.  You can
ignore program error signals like <CODE>SIGSEGV</CODE>, but ignoring the error
won't enable the program to continue executing meaningfully.  Ignoring
user requests such as <CODE>SIGINT</CODE>, <CODE>SIGQUIT</CODE>, and <CODE>SIGTSTP</CODE>
is unfriendly.
<P>
When you do not wish signals to be delivered during a certain part of
the program, the thing to do is to block them, not ignore them.
See section <A HREF="library_21.html#SEC368" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC368">Blocking Signals</A>.
<P>
<DT><CODE><VAR>handler</VAR></CODE>
<DD>Supply the address of a handler function in your program, to specify
running this handler as the way to deliver the signal.
<P>
For more information about defining signal handler functions,
see section <A HREF="library_21.html#SEC351" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC351">Defining Signal Handlers</A>.
</DL>
<P>
If you set the action for a signal to <CODE>SIG_IGN</CODE>, or if you set it