doc: revise blocking vs non-blocking

additional clarifications
nodejs · jrit · Feb 19, 2016 · Feb 21, 2016 · Feb 24, 2016 · Mar 17, 2016
commit 417866056121e687128b3f20970b8756143430a4
diff --git a/doc/topics/blocking-vs-non-blocking.md b/doc/topics/blocking-vs-non-blocking.md
@@ -14,22 +14,25 @@ network supported by [libuv](http://libuv.org/).
 **Blocking** is when the execution of additional JavaScript in the Node.js
 process must wait until a non-JavaScript operation completes. This happens
 because the event loop is unable to continue running JavaScript while a
-**blocking** operation is executing.
+**blocking** operation is occurring.
 
 In Node.js, JavaScript that exhibits poor performance due to being CPU intensive
 rather than waiting on a non-JavaScript operation, such as I/O, isn't typically
 referred to as **blocking**. Synchronous methods in the Node.js standard library
 that use libuv are the most commonly used **blocking** operations. Native
 modules may also have **blocking** methods.
 
-All of the I/O methods in the Node.js standard libraries provide asynchronous
+All of the I/O methods in the Node.js standard library provide asynchronous
 versions, which are **non-blocking**, and accept callback functions. Some
-methods also have **blocking** counterparts, which usually have names that end
-with `Sync`.
+methods also have **blocking** counterparts, which have names that end with
+`Sync`.
 
 
 ## Comparing Code
 
+**Blocking** methods execute **synchronously** and **non-blocking** methods
+execute **asynchronously**.
+
 Using the File System module as an example, this is a **synchronous** file read:
 
 ```js
@@ -46,11 +49,11 @@ fs.readFile('/file.md', (err, data) => {
 });
 ```
 
-The first example appears simpler but it has the disadvantage of the second line
-**blocking** the execution of any additional JavaScript until the entire file is
-read. Note that in the synchronous version if an error is thrown it will need to
-be caught or the process will crash. In the asynchronous version, it is up to
-the author to decide whether an error should throw as shown.
+The first example appears simpler than the second but has the disadvantage of
+the second line **blocking** the execution of any additional JavaScript until
+the entire file is read. Note that in the synchronous version if an error is
+thrown it will need to be caught or the process will crash. In the asynchronous version, it is up to the author to decide whether an error should throw as
+shown.
 
 Let's expand our example a little bit:
 
@@ -76,16 +79,16 @@ In the first example above, `console.log` will be called before `moreWork()`. In
 the second example `fs.readFile()` is **non-blocking** so JavaScript execution
 can continue and `moreWork()` will be called first. The ability to run
 `moreWork()` without waiting for the file read to complete is a key design
-choice that allows for higher throughout.
+choice that allows for higher throughput.
 
 
 ## Concurrency and Throughput
 
 JavaScript execution in Node.js is single threaded, so concurrency refers to the
 event loop's capacity to execute JavaScript callback functions after completing
-other work. Any code that is expected to process requests in a concurrent manner
-depends on the ability of the event loop to continue running as non-JavaScript
-operations like I/O are happening.
+other work. Any code that is expected to run in a concurrent manner must allow
+the event loop to continue running as non-JavaScript operations, like I/O, are
+occurring.
 
 As an example, let's consider a case where each request to a web server takes
 50ms to complete and 45ms of that 50ms is database I/O that can be done
@@ -125,7 +128,7 @@ const fs = require('fs');
 fs.readFile('/file.md', (err, data) => {
   if (err) throw err;
   console.log(data);
-  fs.unlink('/file.md', err => {
+  fs.unlink('/file.md', (err) => {
     if (err) throw err;
   });
 });