ExecutionContext

@implicitNotFound("Cannot find an implicit ExecutionContext. You might add\nan (implicit ec: ExecutionContext) parameter to your method.\n\nThe ExecutionContext is used to configure how and on which\nthread pools asynchronous tasks (such as Futures) will run,\nso the specific ExecutionContext that is selected is important.\n\nIf your application does not define an ExecutionContext elsewhere,\nconsider using Scala\'s global ExecutionContext by defining\nthe following:\n\nimplicit val ec: scala.concurrent.ExecutionContext = scala.concurrent.ExecutionContext.global")

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 define the 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.

Companion:
object
Source:
ExecutionContext.scala
class Object
trait Matchable
class Any

Value members

Abstract methods

def execute(runnable: Runnable): Unit

Runs a block of code on this execution context.

Runs a block of code on this execution context.

Value parameters:
runnable

the task to execute

Source:
ExecutionContext.scala

Reports that an asynchronous computation failed.

Reports that an asynchronous computation failed.

Value parameters:
cause

the cause of the failure

Source:
ExecutionContext.scala

Deprecated methods

@deprecated("preparation of ExecutionContexts will be removed", "2.12.0")

Prepares for the execution of a task.

Prepares for the execution of a task. Returns the prepared execution context. The recommended implementation of prepare is to return this.

This method should no longer be overridden or called. It was originally expected that prepare would be called by all libraries that consume ExecutionContexts, in order to capture thread local context. However, this usage has proven difficult to implement in practice and instead it is now better to avoid using prepare entirely.

Instead, if an ExecutionContext needs to capture thread local context, it should capture that context when it is constructed, so that it doesn't need any additional preparation later.

Deprecated
Source:
ExecutionContext.scala