10000 Update overviews/core/_posts/2012-09-20-futures.md by axel22 · Pull Request #151 · scala/docs.scala-lang · GitHub
[go: up one dir, main page]

Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 8, 2013
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Update overviews/core/_posts/2012-09-20-futures.md
  • Loading branch information
axel22 committed Jan 7, 2013
commit 6a9d70e5d2cabd4fa1c6bd70562acc823ab7476a
15 changes: 7 additions & 8 deletions overviews/core/_posts/2012-09-20-futures.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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:

Expand All @@ -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._

Expand Down
0