signal.texi

一个C源代码分析器

@code{SIGCONT} always makes the process continue regardless.

Most programs have no reason to handle @code{SIGCONT}; they simply
resume execution without realizing they were ever stopped.  You can use
a handler for @code{SIGCONT} to make a program do something special when
it is stopped and continued---for example, to reprint a prompt when it
is suspended while waiting for input.
@end deftypevr

@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGSTOP
The @code{SIGSTOP} signal stops the process.  It cannot be handled,
ignored, or blocked.
@end deftypevr
@cindex stop signal

@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGTSTP
The @code{SIGTSTP} signal is an interactive stop signal.  Unlike
@code{SIGSTOP}, this signal can be handled and ignored.  

Your program should handle this signal if you have a special need to
leave files or system tables in a secure state when a process is
stopped.  For example, programs that turn off echoing should handle
@code{SIGTSTP} so they can turn echoing back on before stopping.

This signal is generated when the user types the SUSP character
(normally @kbd{C-z}).  For more information about terminal driver
support, see @ref{Special Characters}.
@end deftypevr
@cindex interactive stop signal

@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGTTIN
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} signal.  The default action for this signal is to
stop the process.  For more information about how this interacts with
the terminal driver, see @ref{Access to the Terminal}.
@end deftypevr
@cindex terminal input signal

@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGTTOU
This is similar to @code{SIGTTIN}, 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.  @code{SIGTTOU} is
only generated for an attempt to write to the terminal if the
@code{TOSTOP} output mode is set; @pxref{Output Modes}.
@end deftypevr
@cindex terminal output signal

While a process is stopped, no more signals can be delivered to it until
it is continued, except @code{SIGKILL} signals and (obviously)
@code{SIGCONT} signals.  The signals are marked as pending, but not
delivered until the process is continued.  The @code{SIGKILL} signal
always causes termination of the process and can't be blocked, handled
or ignored.  You can ignore @code{SIGCONT}, but it always causes the
process to be continued anyway if it is stopped.  Sending a
@code{SIGCONT} signal to a process causes any pending stop signals for
that process to be discarded.  Likewise, any pending @code{SIGCONT}
signals for a process are discarded when it receives a stop signal.

When a process in an orphaned process group (@pxref{Orphaned Process
Groups}) receives a @code{SIGTSTP}, @code{SIGTTIN}, or @code{SIGTTOU}
signal and does not handle it, the process does not stop.  Stopping the
process would probably not be very useful, since there is no shell
program that will notice it stop and allow the user 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} or @code{SIGHUP}.  In the GNU system, the process
dies with @code{SIGKILL}; this avoids the problem of many stopped,
orphaned processes lying around the system.

@ignore
On the GNU system, it is possible to reattach to the orphaned process
group and continue it, so stop signals do stop the process as usual on
a GNU system unless you have requested POSIX compatibility ``till it
hurts.''
@end ignore

@node Operation Error Signals
@subsection Operation Error Signals

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
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}.

Another cause of @code{SIGPIPE} is when you try to output to a socket
that isn't connected.  @xref{Sending Data}.
@end deftypevr

@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{Limits on Resources}.
@end deftypevr

@comment signal.h
@comment BSD
@deftypevr Macro int 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{Limits on Resources}.
@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
@end deftypevr
@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 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}.

The default action is to terminate the process.
@end deftypevr

@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{Signal Characters}.

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
@cindex signal messages

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} and
@code{psignal}.  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 (@pxref{Process Completion}) or it
may come from a signal handler in the same process.

@comment string.h
@comment GNU
@deftypefun {char *} strsignal (int @var{signum})
This function returns a pointer to a statically-allocated string
containing a message describing the signal @var{signum}.  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.

@pindex string.h
This function is a GNU extension, declared in the header file
@file{string.h}.
@end deftypefun

@comment signal.h
@comment BSD
@deftypefun void psignal (int @var{signum}, const char *@var{message})
This function prints a message describing the signal @var{signum} to the
standard error output stream @code{stderr}; see @ref{Standard Streams}.

If you call @code{psignal} with a @var{message} that is either a null
pointer or an empty string, @code{psignal} just prints the message 
corresponding to @var{signum}, adding a trailing newline.

If you supply a non-null @var{message} argument, then @code{psignal}
prefixes its output with this string.  It adds a colon and a space 
character to separate the @var{message} from the string corresponding
to @var{signum}.

@pindex stdio.h
This function is a BSD feature, declared in the header file @file{signal.h}.
@end deftypefun

@vindex sys_siglist
There is also an array @code{sys_siglist} which contains the messages
for the various signal codes.  This array exists on BSD systems, unlike
@code{strsignal}.

@node Signal Actions
@section Specifying Signal Actions
@cindex signal actions
@cindex establishing a handler

The simplest way to change the action for a signal is to use the
@code{signal} function.  You can specify a built-in action (such as to
ignore the signal), or you can @dfn{establish a handler}.

The GNU library also implements the more versatile @code{sigaction}
facility.  This section describes both facilities and gives suggestions
on which to use when.

@menu
* Basic Signal Handling::       The simple @code{signal} function.
* Advanced Signal Handling::    The more powerful @code{sigaction} function.
* Signal and Sigaction::        How those two functions interact.
* Sigaction Function Example::  An example of using the sigaction function.
* Flags for Sigaction::         Specifying options for signal handling.
* Initial Signal Actions::      How programs inherit signal actions.
@end menu

@node Basic Signal Handling
@subsection Basic Signal Handling
@cindex @code{signal} function

The @code{signal} function provides a simple interface for establishing
an action for a particular signal.  The function and associated macros
are declared in the header file @file{signal.h}.
@pindex signal.h

@comment signal.h
@comment GNU
@deftp {Data Type} sighandler_t
This is the type of signal handler functions.  Signal handlers take one
integer argument specifying the signal number, and have return type
@code{void}.  So, you should define handler functions like this:

@smallexample
void @var{handler} (int @code{signum}) @{ @dots{} @}
@end smallexample

The name @code{sighandler_t} for this data type is a GNU extension.
@end deftp

@comment signal.h
@comment ANSI
@deftypefun sighandler_t signal (int @var{signum}, sighandler_t @var{action})
The @code{signal} function establishes @var{action} as the action for
the signal @var{signum}.

The first argument, @var{signum}, 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 @ref{Standard Signals}---don't use an explicit number, because
the numerical code for a given kind of signal may vary from operating
system to operating system.

The second argument, @var{action}, specifies the action to use for the
signal @var{signum}.  This can be one of the following:

@table @code
@item SIG_DFL
@vindex SIG_DFL
@cindex default action for a signal
@code{SIG_DFL} specifies the default action for the particular signal.
The default actions for various kinds of signals are stated in
@ref{Standard Signals}.

@item SIG_IGN
@vindex SIG_IGN
@cindex ignore action for a signal
@code{SIG_IGN} specifies that the signal should be ignored.

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} or @code{SIGSTOP} signals at all.  You can
ignore program error signals like @code{SIGSEGV}, but ignoring the error
won't enable the program to continue executing meaningfully.  Ignoring
user requests such as @code{SIGINT}, @code{SIGQUIT}, and @code{SIGTSTP}
is unfriendly.

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.
@xref{Blocking Signals}.

@item @var{handler}
Supply the address of a handler function in your program, to specify
running this handler as the way to deliver the signal.

For more information about defining signal handler functions,
see @ref{Defining Handlers}.
@end table

If you set the action for a signal to @code{SIG_IGN}, or if you set it
to @code{SIG_DFL} and the default action is to ignore that signal, then
any pending signals of that type are discarded (even if they are
blocked).  Discarding the pending signals means that they will never be
delivered, not even if you subsequently specify another action and
unblock this kind of signal.