1 files changed, 7 insertions, 7 deletions
diff --git a/technical/api-simple-ipc.html b/technical/api-simple-ipc.html
index 04e0c9dec..5d2e56db2 100644
--- a/technical/api-simple-ipc.html
+++ b/technical/api-simple-ipc.html
@@ -735,13 +735,13 @@ asciidoc.install();
 <body class="article">
 <div id="header">
 <h1>Simple-IPC API</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
 </div>
 <div id="content">
 <div id="preamble">
 <div class="sectionbody">
 <div class="paragraph"><p>The Simple-IPC API is a collection of <code>ipc_</code> prefixed library routines
-and a basic communication protocol that allow an IPC-client process to
+and a basic communication protocol that allows an IPC-client process to
 send an application-specific IPC-request message to an IPC-server
 process and receive an application-specific IPC-response message.</p></div>
 <div class="paragraph"><p>Communication occurs over a named pipe on Windows and a Unix domain
@@ -756,11 +756,11 @@ IPC-server routines then incrementally relay responses back to the
 IPC-client.</p></div>
 <div class="paragraph"><p>The IPC-client routines within a client application process connect
 to the IPC-server and send a request message and wait for a response.
-When received, the response is returned back the caller.</p></div>
+When received, the response is returned back to the caller.</p></div>
 <div class="paragraph"><p>For example, the <code>fsmonitor--daemon</code> feature will be built as a server
 application on top of the IPC-server library routines.  It will have
 threads watching for file system events and a thread pool waiting for
-client connections.  Clients, such as <code>git status</code> will request a list
+client connections.  Clients, such as <code>git status</code>, will request a list
 of file system events since a point in time and the server will
 respond with a list of changed files and directories.  The formats of
 the request and response are application-specific; the IPC-client and
@@ -772,7 +772,7 @@ IPC-server routines treat them as opaque byte streams.</p></div>
 <div class="sectionbody">
 <div class="paragraph"><p>The Simple-IPC mechanism differs from the existing <code>sub-process.c</code>
 model (Documentation/technical/long-running-process-protocol.txt) and
-used by applications like Git-LFS.  In the LFS-style sub-process model
+used by applications like Git-LFS.  In the LFS-style sub-process model,
 the helper is started by the foreground process, communication happens
 via a pair of file descriptors bound to the stdin/stdout of the
 sub-process, the sub-process only serves the current foreground
@@ -833,7 +833,7 @@ stateless request, receive an application-specific
 response, and disconnect.  It is a one round trip facility for
 querying the server.  The Simple-IPC routines hide the socket,
 named pipe, and thread pool details and allow the application
-layer to focus on the application at hand.</p></div>
+layer to focus on the task at hand.</p></div>
 </div>
 </div>
 </div>
@@ -841,7 +841,7 @@ layer to focus on the application at hand.</p></div>
 <div id="footer">
 <div id="footer-text">
 Last updated
- 2022-08-18 14:11:07 PDT
+ 2023-10-23 14:43:46 PDT
 </div>
 </div>
 </body>