summaryrefslogtreecommitdiff
path: root/src/library/scala/concurrent/package.scala
diff options
context:
space:
mode:
Diffstat (limited to 'src/library/scala/concurrent/package.scala')
-rw-r--r--src/library/scala/concurrent/package.scala57
1 files changed, 41 insertions, 16 deletions
diff --git a/src/library/scala/concurrent/package.scala b/src/library/scala/concurrent/package.scala
index d159dda414..0695ee3351 100644
--- a/src/library/scala/concurrent/package.scala
+++ b/src/library/scala/concurrent/package.scala
@@ -20,14 +20,33 @@ import scala.annotation.implicitNotFound
* [[http://docs.scala-lang.org/overviews/core/futures.html]].
*
* == Common Imports ==
- *
+ *
* When working with Futures, you will often find that importing the whole concurrent
- * package is convenient, furthermore you are likely to need an implicit ExecutionContext
- * in scope for many operations involving Futures and Promises:
- *
+ * package is convenient:
+ *
* {{{
* import scala.concurrent._
- * import ExecutionContext.Implicits.global
+ * }}}
+ *
+ * When using things like `Future`s, it is often required to have an implicit `ExecutionContext`
+ * in scope. The general advice for these implicits are as follows.
+ *
+ * If the code in question is a class or method definition, and no `ExecutionContext` is available,
+ * request one from the caller by adding an implicit parameter list:
+ *
+ * {{{
+ * def myMethod(myParam: MyType)(implicit ec: ExecutionContext) = …
+ * //Or
+ * class MyClass(myParam: MyType)(implicit ec: ExecutionContext) { … }
+ * }}}
+ *
+ * This allows the caller of the method, or creator of the instance of the class, to decide which
+ * `ExecutionContext` should be used.
+ *
+ * For typical REPL usage and experimentation, importing the global `ExecutionContext` is often desired.
+ *
+ * {{{
+ * import scala.concurrent.ExcutionContext.Implicits.global
* }}}
*
* == Specifying Durations ==
@@ -41,7 +60,7 @@ import scala.annotation.implicitNotFound
* }}}
*
* == Using Futures For Non-blocking Computation ==
- *
+ *
* Basic use of futures is easy with the factory method on Future, which executes a
* provided function asynchronously, handing you back a future result of that function
* without blocking the current thread. In order to create the Future you will need
@@ -50,7 +69,7 @@ import scala.annotation.implicitNotFound
* {{{
* import scala.concurrent._
* import ExecutionContext.Implicits.global // implicit execution context
- *
+ *
* val firstZebra: Future[Int] = Future {
* val source = scala.io.Source.fromFile("/etc/dictionaries-common/words")
* source.toSeq.indexOfSlice("zebra")
@@ -80,7 +99,7 @@ import scala.annotation.implicitNotFound
* animalRange.onSuccess {
* case x if x > 500000 => println("It's a long way from Aardvark to Zebra")
* }
- * }}}
+ * }}}
*/
package object concurrent {
type ExecutionException = java.util.concurrent.ExecutionException
@@ -96,7 +115,7 @@ package object concurrent {
* @param executor the execution context on which the future is run
* @return the `Future` holding the result of the computation
*/
- @deprecated("Use `Future { ... }` instead.", "2.11.0")
+ @deprecated("use `Future { ... }` instead", "2.11.0")
// removal planned for 2.13.0
def future[T](body: =>T)(implicit @deprecatedName('execctx) executor: ExecutionContext): Future[T] = Future[T](body)
@@ -105,7 +124,7 @@ package object concurrent {
* @tparam T the type of the value in the promise
* @return the newly created `Promise` object
*/
- @deprecated("Use `Promise[T]()` instead.", "2.11.0")
+ @deprecated("use `Promise[T]()` instead", "2.11.0")
// removal planned for 2.13.0
def promise[T](): Promise[T] = Promise[T]()
@@ -140,17 +159,20 @@ package concurrent {
/**
* `Await` is what is used to ensure proper handling of blocking for `Awaitable` instances.
*
- * While occasionally useful, e.g. for testing, it is recommended that you avoid Await
- * when possible in favor of callbacks and combinators like onComplete and use in
- * for comprehensions. Await will block the thread on which it runs, and could cause
- * performance and deadlock issues.
+ * While occasionally useful, e.g. for testing, it is recommended that you avoid Await whenever possible—
+ * instead favoring combinators and/or callbacks.
+ * Await's `result` and `ready` methods will block the calling thread's execution until they return,
+ * which will cause performance degradation, and possibly, deadlock issues.
*/
object Await {
/**
* Await the "completed" state of an `Awaitable`.
*
* Although this method is blocking, the internal use of [[scala.concurrent.blocking blocking]] ensures that
- * the underlying [[ExecutionContext]] is prepared to properly manage the blocking.
+ * the underlying [[ExecutionContext]] is given an opportunity to properly manage the blocking.
+ *
+ * WARNING: It is strongly discouraged to supply lengthy timeouts since the progress of the calling thread will be
+ * suspended—blocked—until either the `Awaitable` becomes ready or the timeout expires.
*
* @param awaitable
* the `Awaitable` to be awaited
@@ -172,7 +194,10 @@ package concurrent {
* Await and return the result (of type `T`) of an `Awaitable`.
*
* Although this method is blocking, the internal use of [[scala.concurrent.blocking blocking]] ensures that
- * the underlying [[ExecutionContext]] to properly detect blocking and ensure that there are no deadlocks.
+ * the underlying [[ExecutionContext]] is given an opportunity to properly manage the blocking.
+ *
+ * WARNING: It is strongly discouraged to supply lengthy timeouts since the progress of the calling thread will be
+ * suspended—blocked—until either the `Awaitable` has a result or the timeout expires.
*
* @param awaitable
* the `Awaitable` to be awaited