Update overviews/core/_posts/2012-09-20-futures.md

axel22 · axel22 · commit 6a9d70e5d2ca · 2013-01-07T13:45:06.000+01:00
diff --git a/overviews/core/_posts/2012-09-20-futures.md b/overviews/core/_posts/2012-09-20-futures.md
@@ -142,8 +142,8 @@ We are often interested in the result of the computation, not just its
 side-effects.
 
 In many future implementations, once the client of the future becomes interested
-in its result, he has to block its own computation and wait until the future is completed--
-only then can he use the value of the future to continue its own computation.
+in its result, it has to block its own computation and wait until the future is completed--
+only then can it use the value of the future to continue its own computation.
 Although this is allowed by the Scala `Future` API as we will show later,
 from a performance point of view a better way to do it is in a completely
 non-blocking way, by registering a callback on the future.
@@ -303,9 +303,7 @@ if the future is completed successfully or fails, respectively.
 
 3. Registering a callback on the future which is already completed
 will result in the callback being executed eventually (as implied by
-1). Furthermore, the callback may even be executed synchronously on
-the same thread that registered the callback if this does not cancel
-progress of that thread.
+1).
 
 4. In the event that multiple callbacks are registered on the future,
 the order in which they are executed is not defined. In fact, the
@@ -314,7 +312,7 @@ However, a particular `ExecutionContext` implementation may result
 in a well-defined order.
 
 5. In the event that some of the callbacks throw an exception, the
-other callbacks are executed regardlessly.
+other callbacks are executed regardless.
 
 6. In the event that some of the callbacks never complete (e.g. the
 callback contains an infinite loop), the other callbacks may not be
@@ -692,6 +690,8 @@ propagation of critical and control-flow related exceptions normally
 not handled by the client code and at the same time inform the client
 in which future the computation failed.
 
+See [`NonFatal`](http://www.scala-lang.org/api/current/index.html#scala.util.control.NonFatal$)
+for a more precise semantics description.
 
 ## Promises
 
@@ -870,7 +870,7 @@ Abstract `Duration` contains methods that allow :
 2. Comparison of durations (`<`, `<=`, `>` and `>=`).
 3. Arithmetic operations (`+`, `-`, `*`, `/` and `unary_-`).
 4. Minimum and maximum between `this` duration and the one supplied in the argument (`min`, `max`).
-5. Check if the duration is finite (`finite_?`).
+5. Check if the duration is finite (`isFinite`).
 
 `Duration` can be instantiated in the following ways:
 
@@ -882,7 +882,6 @@ For example `val d = Duration(100, MILLISECONDS)`.
 Duration also provides `unapply` methods so it can be used in pattern matching constructs.
 Examples:
 
-    import scala.concurrent.Duration
     import scala.concurrent.duration._
     import java.util.concurrent.TimeUnit._
  
