addressing review comments

backuitist · backuitist · commit e61c7f5d4f14 · 2015-07-21T18:20:55.000+02:00
diff --git a/overviews/core/_posts/2012-09-20-futures.md b/overviews/core/_posts/2012-09-20-futures.md
@@ -618,26 +618,37 @@ This will allow external frameworks to provide more specialized utilities.
 
 ## Blocking
 
-### in a Future
+Futures are generally asynchronous and do not block the underlying execution threads.
+However, in certain cases, it is necessary to block.
+We distinguish two forms of blocking the execution thread:
+invoking arbitrary code that blocks the thread from within the future,
+and blocking from outside another future, waiting until that future gets completed.
+
+
+### Blocking inside a Future
 
 As seen with the global `ExecutionContext`, it is possible to notify an `ExecutionContext` of a blocking call with the `blocking` construct.
 The implementation is however at the complete discretion of the `ExecutionContext`. While some `ExecutionContext` such as `ExecutionContext.global`
-implement `blocking` by means of `ManagedBlocker`, some just do nothing:
+implement `blocking` by means of a `ManagedBlocker`, some execution contexts such as the fixed thread pool: 
+
+    ExecutionContext.fromExecutor(Executors.newFixedThreadPool(x))
+
+will do nothing, as shown in the following:
 
     implicit val ec = ExecutionContext.fromExecutor(
                         Executors.newFixedThreadPool(4))
     Future {
-      // here blocking serves only for documentation purpose
       blocking { blockingStuff() }
     }
 
-Is equivalent to
+Has the same effect as
  
     Future { blockingStuff() }
 
 The blocking code may also throw an exception. In this case, the exception is forwarded to the caller.
 
-### on a Future
+
+### Blocking outside the Future
 
 As mentioned earlier, blocking on a future is strongly discouraged
 for the sake of performance and for the prevention of deadlocks.
