Re: FYI: fix race condition in elisp's recover rule

[Alexandre Duret-Lutz]

>>> "Jim" == Jim Meyering <address@hidden> writes:

 Jim> Hi Alexandre!
 Jim> Here are a couple of minor suggested wording changes.

Thanks for the corrections.

2005-03-29  Alexandre Duret-Lutz  <address@hidden>

        * doc/automake.texi (Multiple Outputs): Fix mistakes reported by
        Jim Meyering.

Index: doc/automake.texi
===================================================================
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.44.2.47
diff -u -r1.44.2.47 automake.texi
--- doc/automake.texi   29 Mar 2005 18:47:09 -0000      1.44.2.47
+++ doc/automake.texi   29 Mar 2005 20:16:52 -0000
@@ -8448,11 +8448,11 @@
 @end example
 
 The above scheme can be extended to handle more outputs and more
-inputs.  One of the output is picked up to serve as a witness of the
-run of the command, it depends upon all inputs, and all other outputs
-depend upon it.  For instance if @command{foo} should additionally
-read @file{data.bar} and also produce @file{data.w} and @file{data.x},
-we would write:
+inputs.  One of the outputs is selected to serve as a witness to the
+successful completion of the command, it depends upon all inputs, and
+all other outputs depend upon it.  For instance if @command{foo}
+should additionally read @file{data.bar} and also produce
address@hidden and @file{data.x}, we would write:
 
 @example
 data.c: data.foo data.bar
@@ -8468,7 +8468,7 @@
 However there are now two minor problems in this setup.  One is related
 to the timestamp ordering of @file{data.h}, @file{data.w},
 @file{data.x}, and @file{data.c}.  The other one is a race condition
-if a parallel @command{make} attempts to run multiple instance of the
+if a parallel @command{make} attempts to run multiple instances of the
 recover block at once.
 
 Let us deal with the first problem.  @command{foo} outputs four files,
@@ -8521,21 +8521,21 @@
 
 This solution still suffers from the second problem: the race
 condition in the recover rule.  If, after a successful build, a user
-erases @file{data.c} and @file{data.h}, and run @samp{make -j}, then
+erases @file{data.c} and @file{data.h}, and runs @samp{make -j}, then
 @command{make} may start both recover rules in parallel.  If the two
 instances of the rule execute @samp{$(MAKE) $(AM_MAKEFLAGS)
 data.stamp} concurrently the build is likely to fail (for instance the
 two rules will create @file{data.tmp}, but only one can rename it).
 
-Admittedly, such weird situation does not happen during ordinary
+Admittedly, such a weird situation does not happen during ordinary
 builds.  It occurs only when the build tree is mutilated.  Here
 @file{data.c} and @file{data.h} have been explicitly removed without
 also removing @file{data.stamp} and the other output files.
 @code{make clean; make} will always recover from these situations even
-with parallel makes, so you may decide that the recover rule is just
+with parallel makes, so you may decide that the recover rule is solely
 an help to non-parallel make users and leave things as-is.  Fixing
 this requires some locking mechanism to ensure only one instance of
-the recover rule rebuild @code{data.stamp}.  One could imagine
+the recover rule rebuilds @code{data.stamp}.  One could imagine
 something along the following lines.
 
 @example
-- 
Alexandre Duret-Lutz