An object that may eventually be completed with a result value of type T which may be awaited using blocking methods.

The Await object provides methods that allow accessing the result of an Awaitable by blocking the current thread until the Awaitable has been completed or a timeout has occurred.

A context to be notified by scala.concurrent.blocking when a thread is about to block. In effect this trait provides the implementation for scala.concurrent.Await. scala.concurrent.Await.result() and scala.concurrent.Await.ready() locates an instance of BlockContext by first looking for one provided through BlockContext.withBlockContext() and failing that, checking whether Thread.currentThread is an instance of BlockContext. So a thread pool can have its java.lang.Thread instances implement BlockContext. There's a default BlockContext used if the thread doesn't implement BlockContext.

Typically, you'll want to chain to the previous BlockContext, like this:

val oldContext = BlockContext.current
val myContext = new BlockContext {
  override def blockOn[T](thunk: =>T)(implicit permission: CanAwait): T = {
    // you'd have code here doing whatever you need to do
    // when the thread is about to block.
    // Then you'd chain to the previous context:
    oldContext.blockOn(thunk)
  }
}
BlockContext.withBlockContext(myContext) {
  // then this block runs with myContext as the handler
  // for scala.concurrent.blocking
}

This marker trait is used by Await to ensure that Awaitable.ready and Awaitable.result are not directly called by user code. An implicit instance of this trait is only available when user code is currently calling the methods on Await.

This class provides a simple FIFO queue of data objects, which are read by one or more reader threads.

A DelayedLazyVal is a wrapper for lengthy computations which have a valid partially computed result.

The first argument is a function for obtaining the result at any given point in time, and the second is the lengthy computation. Once the computation is complete, the apply method will stop recalculating it and return a fixed value from that point forward.

An ExecutionContext can execute program logic asynchronously, typically but not necessarily on a thread pool.

A general purpose ExecutionContext must be asynchronous in executing any Runnable that is passed into its execute-method. A special purpose ExecutionContext may be synchronous but must only be passed to code that is explicitly safe to be run using a synchronously executing ExecutionContext.

APIs such as Future.onComplete require you to provide a callback and an implicit ExecutionContext. The implicit ExecutionContext will be used to execute the callback.

While it is possible to simply import scala.concurrent.ExecutionContext.Implicits.global to obtain an implicit ExecutionContext, application developers should carefully consider where they want to set execution policy; ideally, one place per application—or per logically related section of code— will make a decision about which ExecutionContext to use. That is, you will mostly want to avoid hardcoding, especially via an import, scala.concurrent.ExecutionContext.Implicits.global. The recommended approach is to add (implicit ec: ExecutionContext) to methods, or class constructor parameters, which need an ExecutionContext.

Then locally import a specific ExecutionContext in one place for the entire application or module, passing it implicitly to individual methods. Alternatively define a local implicit val with the required ExecutionContext.

A custom ExecutionContext may be appropriate to execute code which blocks on IO or performs long-running computations. ExecutionContext.fromExecutorService and ExecutionContext.fromExecutor are good ways to create a custom ExecutionContext.

The intent of ExecutionContext is to lexically scope code execution. That is, each method, class, file, package, or application determines how to run its own code. This avoids issues such as running application callbacks on a thread pool belonging to a networking library. The size of a networking library's thread pool can be safely configured, knowing that only that library's network operations will be affected. Application callback execution can be configured separately.

A Future represents a value which may or may not *currently* be available, but will be available at some point, or an exception if that value could not be made available.

Asynchronous computations that yield futures are created with the Future.apply call and are computed using a supplied ExecutionContext, which can be backed by a Thread pool.

import ExecutionContext.Implicits.global
val s = "Hello"
val f: Future[String] = Future {
  s + " future!"
}
f foreach {
  msg => println(msg)
}

A marker indicating that a java.lang.Runnable provided to scala.concurrent.ExecutionContext wraps a callback provided to Future.onComplete. All callbacks provided to a Future end up going through onComplete, so this allows an ExecutionContext to special-case callbacks that were executed by Future if desired.

A SyncChannel allows one to exchange data synchronously between a reader and a writer thread. The writer thread is blocked until the data to be written has been read by a corresponding reader thread.

A class to provide safe concurrent access to a mutable cell. All methods are synchronized.

This class ...