doc: suggestions for design page

While reading the design page I came across a few sentences that could
perhaps be improved, and this commit contains suggestions for such
improvements.

PR-URL: https://github.com/libuv/libuv/pull/1302
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>

1 files changed, 9 insertions, 8 deletions

diff --git a/docs/src/design.rst b/docs/src/design.rst
index ecf2609b..487d08ba 100644
--- a/docs/src/design.rst
+++ b/docs/src/design.rst
@@ -7,7 +7,7 @@ Design overview
 libuv is cross-platform support library which was originally written for NodeJS. It's designed
 around the event-driven asynchronous I/O model.
 
-The library provides much more than simply abstraction over different I/O polling mechanisms:
+The library provides much more than a simple abstraction over different I/O polling mechanisms:
 'handles' and 'streams' provide a high level abstraction for sockets and other entities;
 cross-platform file I/O and threading functionality is also provided, amongst other things.
 
@@ -25,9 +25,10 @@ Handles and requests
 libuv provides users with 2 abstractions to work with, in combination with the event loop:
 handles and requests.
 
-Handles represent long-lived objects capable of performing certain operations while active. Some
-examples: a prepare handle gets its callback called once every loop iteration when active, and
-a TCP server handle get its connection callback called every time there is a new connection.
+Handles represent long-lived objects capable of performing certain operations while active. Some examples:
+
+- A prepare handle gets its callback called once every loop iteration when active.
+- A TCP server handle that gets its connection callback called every time there is a new connection.
 
 Requests represent (typically) short-lived operations. These operations can be performed over a
 handle: write requests are used to write data on a handle; or standalone: getaddrinfo requests
@@ -85,11 +86,11 @@ stages of a loop iteration:
         * If there are no active handles or requests, the timeout is 0.
         * If there are any idle handles active, the timeout is 0.
         * If there are any handles pending to be closed, the timeout is 0.
-        * If none of the above cases was matched, the timeout of the closest timer is taken, or
+        * If none of the above cases matches, the timeout of the closest timer is taken, or
           if there are no active timers, infinity.
 
-#. The loop blocks for I/O. At this point the loop will block for I/O for the timeout calculated
-   on the previous step. All I/O related handles that were monitoring a given file descriptor
+#. The loop blocks for I/O. At this point the loop will block for I/O for the duration calculated
+   in the previous step. All I/O related handles that were monitoring a given file descriptor
    for a read or write operation get their callbacks called at this point.
 
 #. Check handle callbacks are called. Check handles get their callbacks called right after the
@@ -103,7 +104,7 @@ stages of a loop iteration:
    so there might be timers which are due, those timers get their callbacks called.
 
 #. Iteration ends. If the loop was run with ``UV_RUN_NOWAIT`` or ``UV_RUN_ONCE`` modes the
-   iteration is ended and :c:func:`uv_run` will return. If the loop was run with ``UV_RUN_DEFAULT``
+   iteration ends and :c:func:`uv_run` will return. If the loop was run with ``UV_RUN_DEFAULT``
    it will continue from the start if it's still *alive*, otherwise it will also end.