blob: 2c68cef6e99a589bd3853476141c939fd6b6c029 [file] [log] [blame]
<html lang="en">
<head>
<title>Signal Generation - The GNU C Library</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="The GNU C Library">
<meta name="generator" content="makeinfo 4.13">
<link title="Top" rel="start" href="index.html#Top">
<link rel="up" href="Concepts-of-Signals.html#Concepts-of-Signals" title="Concepts of Signals">
<link rel="prev" href="Kinds-of-Signals.html#Kinds-of-Signals" title="Kinds of Signals">
<link rel="next" href="Delivery-of-Signal.html#Delivery-of-Signal" title="Delivery of Signal">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<!--
This file documents the GNU C library.
This is Edition 0.12, last updated 2007-10-27,
of `The GNU C Library Reference Manual', for version
2.8 (Sourcery G++ Lite 2011.03-41).
Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002,
2003, 2007, 2008, 2010 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with the
Invariant Sections being ``Free Software Needs Free Documentation''
and ``GNU Lesser General Public License'', the Front-Cover texts being
``A GNU Manual'', and with the Back-Cover Texts as in (a) below. A
copy of the license is included in the section entitled "GNU Free
Documentation License".
(a) The FSF's Back-Cover Text is: ``You have the freedom to
copy and modify this GNU manual. Buying copies from the FSF
supports it in developing GNU and promoting software freedom.''-->
<meta http-equiv="Content-Style-Type" content="text/css">
<style type="text/css"><!--
pre.display { font-family:inherit }
pre.format { font-family:inherit }
pre.smalldisplay { font-family:inherit; font-size:smaller }
pre.smallformat { font-family:inherit; font-size:smaller }
pre.smallexample { font-size:smaller }
pre.smalllisp { font-size:smaller }
span.sc { font-variant:small-caps }
span.roman { font-family:serif; font-weight:normal; }
span.sansserif { font-family:sans-serif; font-weight:normal; }
--></style>
<link rel="stylesheet" type="text/css" href="../cs.css">
</head>
<body>
<div class="node">
<a name="Signal-Generation"></a>
<p>
Next:&nbsp;<a rel="next" accesskey="n" href="Delivery-of-Signal.html#Delivery-of-Signal">Delivery of Signal</a>,
Previous:&nbsp;<a rel="previous" accesskey="p" href="Kinds-of-Signals.html#Kinds-of-Signals">Kinds of Signals</a>,
Up:&nbsp;<a rel="up" accesskey="u" href="Concepts-of-Signals.html#Concepts-of-Signals">Concepts of Signals</a>
<hr>
</div>
<h4 class="subsection">24.1.2 Concepts of Signal Generation</h4>
<p><a name="index-generation-of-signals-2811"></a>
In general, the events that generate signals fall into three major
categories: errors, external events, and explicit requests.
<p>An error means that a program has done something invalid and cannot
continue execution. But not all kinds of errors generate signals&mdash;in
fact, most do not. For example, opening a nonexistent file is an error,
but it does not raise a signal; instead, <code>open</code> returns <code>-1</code>.
In general, errors that are necessarily associated with certain library
functions are reported by returning a value that indicates an error.
The errors which raise signals are those which can happen anywhere in
the program, not just in library calls. These include division by zero
and invalid memory addresses.
<p>An external event generally has to do with I/O or other processes.
These include the arrival of input, the expiration of a timer, and the
termination of a child process.
<p>An explicit request means the use of a library function such as
<code>kill</code> whose purpose is specifically to generate a signal.
<p>Signals may be generated <dfn>synchronously</dfn> or <dfn>asynchronously</dfn>. A
synchronous signal pertains to a specific action in the program, and is
delivered (unless blocked) during that action. Most errors generate
signals synchronously, and so do explicit requests by a process to
generate a signal for that same process. On some machines, certain
kinds of hardware errors (usually floating-point exceptions) are not
reported completely synchronously, but may arrive a few instructions
later.
<p>Asynchronous signals are generated by events outside the control of the
process that receives them. These signals arrive at unpredictable times
during execution. External events generate signals asynchronously, and
so do explicit requests that apply to some other process.
<p>A given type of signal is either typically synchronous or typically
asynchronous. For example, signals for errors are typically synchronous
because errors generate signals synchronously. But any type of signal
can be generated synchronously or asynchronously with an explicit
request.
</body></html>