Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Play's execution contexts vs scala global

How does the execution context from

import scala.concurrent.ExecutionContext.Implicits.global 

differ from Play's execution contexts:

import play.core.Execution.Implicits.{internalContext, defaultContext} 
like image 309
bjfletcher Avatar asked Jun 12 '15 14:06

bjfletcher


People also ask

What is Scala execution context?

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.

What is the global ExecutionContext?

Whenever the JavaScript engine receives a script file, it first creates a default Execution Context known as the Global Execution Context (GEC) . The GEC is the base/default Execution Context where all JavaScript code that is not inside of a function gets executed. For every JavaScript file, there can only be one GEC.


1 Answers

They are very different.

In Play 2.3.x and prior, play.core.Execution.Implicits.internalContext is a ForkJoinPool with fixed constraints on size, used internally by Play. You should never use it for your application code. From the docs:

Play Internal Thread Pool - This is used internally by Play. No application code should ever be executed by a thread in this thread pool, and no blocking should ever be done in this thread pool. Its size can be configured by setting internal-threadpool-size in application.conf, and it defaults to the number of available processors.

Instead, you would use play.api.libs.concurrent.Execution.Implicits.defaultContext, which uses an ActorSystem.

In 2.4.x, they both use the same ActorSystem. This means that Akka will distribute work among its own pool of threads, but in a way that is invisible to you (other than configuration). Several Akka actors can share the same thread.

scala.concurrent.ExecutionContext.Implicits.global is an ExecutionContext defined in the Scala standard library. It is a special ForkJoinPool that using the blocking method to handle potentially blocking code in order to spawn new threads in the pool. You really shouldn't use this in a Play application, as Play will have no control over it. It also has the potential to spawn a lot of threads and use a ton of memory, if you're not careful.

I've written more about scala.concurrent.ExecutionContext.Implicits.global in this answer.

like image 61
Michael Zajac Avatar answered Sep 29 '22 19:09

Michael Zajac