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

1 files changed, 12 insertions, 12 deletions

diff --git a/manual/signal.texi b/manual/signal.texi
index 15458c2..08ee785 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}.