aboutsummaryrefslogtreecommitdiffstats
path: root/manual/signal.texi
diff options
context:
space:
mode:
authorUlrich Drepper <drepper@redhat.com>1999-08-27 19:06:58 +0000
committerUlrich Drepper <drepper@redhat.com>1999-08-27 19:06:58 +0000
commit04b9968b398bb0ca100a102ad36ba089d434d5fa (patch)
treeb8ca0cd1a9bc840473f1b9f2af5765c338d3ddb4 /manual/signal.texi
parent77faa3541634894476d904cd517e81f57cfa4fe2 (diff)
downloadtermbaud-04b9968b398bb0ca100a102ad36ba089d434d5fa.tar.gz
termbaud-04b9968b398bb0ca100a102ad36ba089d434d5fa.tar.xz
termbaud-04b9968b398bb0ca100a102ad36ba089d434d5fa.zip
Update.
1999-08-27 Ulrich Drepper <drepper@cygnus.com> * manual/argp.texi: Fixing language and types. * manual/conf.texi: Likewise. * manual/contrib.texi: Likewise. * manual/filesys.texi: Likewise. * manual/install.texi: Likewise. * manual/job.texi: Likewise. * manual/lang.texi: Likewise. * manual/llio.texi: Likewise. * manual/math.texi: Likewise. * manual/nss.texi: Likewise. * manual/pipe.texi: Likewise. * manual/signal.texi: Likewise. * manual/socket.texi: Likewise. * manual/stdio.texi: Likewise. * manual/sysinfo.texi: Likewise. * manual/users.texi: Likewise. Patches by Neil Booth <NeilB@earthling.net>.
Diffstat (limited to 'manual/signal.texi')
-rw-r--r--manual/signal.texi24
1 files changed, 12 insertions, 12 deletions
diff --git a/manual/signal.texi b/manual/signal.texi
index 15458c208e6..08ee785c8cc 100644
--- a/manual/signal.texi
+++ b/manual/signal.texi
@@ -1659,7 +1659,7 @@ the past.
Here is an example of a handler for @code{SIGCHLD} that compensates for
the fact that the number of signals received may not equal the number of
-child processes generate them. It assumes that the program keeps track
+child processes that generate them. It assumes that the program keeps track
of all the child processes with a chain of structures as follows:
@smallexample
@@ -1809,7 +1809,7 @@ sig_atomic_t last_process_status_change;
Handler functions usually don't do very much. The best practice is to
write a handler that does nothing but set an external variable that the
program checks regularly, and leave all serious work to the program.
-This is best because the handler can be called at asynchronously, at
+This is best because the handler can be called asynchronously, at
unpredictable times---perhaps in the middle of a primitive function, or
even between the beginning and the end of a C operator that requires
multiple instructions. The data structures being manipulated might
@@ -1856,8 +1856,8 @@ blocks signals around each use, then you are safe.
There are a large number of library functions that return values in a
fixed object, always reusing the same object in this fashion, and all of
-them cause the same problem. The description of a function in this
-manual always mentions this behavior.
+them cause the same problem. Function descriptions in this manual
+always mention this behavior.
@item
If a function uses and modifies an object that you supply, then it is
@@ -1940,7 +1940,7 @@ Whether the data in your application concerns atoms, or mere text, you
have to be careful about the fact that access to a single datum is not
necessarily @dfn{atomic}. This means that it can take more than one
instruction to read or write a single object. In such cases, a signal
-handler might in the middle of reading or writing the object.
+handler might be invoked in the middle of reading or writing the object.
There are three ways you can cope with this problem. You can use data
types that are always accessed atomically; you can carefully arrange
@@ -2031,9 +2031,9 @@ atomically.
In practice, you can assume that @code{int} and other integer types no
longer than @code{int} are atomic. You can also assume that pointer
-types are atomic; that is very convenient. Both of these are true on
-all of the machines that the GNU C library supports, and on all POSIX
-systems we know of.
+types are atomic; that is very convenient. Both of these assumptions
+are true on all of the machines that the GNU C library supports and on
+all POSIX systems we know of.
@c ??? This might fail on a 386 that uses 64-bit pointers.
@node Atomic Usage
@@ -2846,7 +2846,7 @@ not only within @code{update_mumble}, but also within the caller. This
is also why we do not check @code{signal_pending} if @code{defer_signal}
is still nonzero.
-The incrementing and decrementing of @code{defer_signal} require more
+The incrementing and decrementing of @code{defer_signal} each require more
than one instruction; it is possible for a signal to happen in the
middle. But that does not cause any problem. If the signal happens
early enough to see the value from before the increment or decrement,
@@ -2932,12 +2932,12 @@ The function was interrupted by delivery of a signal.
If the signal causes program termination, @code{pause} doesn't return
(obviously).
-This function is a cancelation point in multi-threaded programs. This
+This function is a cancellation point in multithreaded programs. This
is a problem if the thread allocates some resources (like memory, file
descriptors, semaphores or whatever) at the time @code{pause} is
-called. If the thread gets canceled these resources stay allocated
+called. If the thread gets cancelled these resources stay allocated
until the program ends. To avoid this calls to @code{pause} should be
-protected using cancelation handlers.
+protected using cancellation handlers.
@c ref pthread_cleanup_push / pthread_cleanup_pop
The @code{pause} function is declared in @file{unistd.h}.