The Akka
documentation says:
you may be tempted to just wrap the blocking call inside a Future and work with that instead, but this strategy is to
Futures are run within execution contexts. This is obvious from the Future
API: any call which involves attaching some callbacks to a future or to build a future from an arbitrary computation or from another future requires an implicitly available ExecutionContext
object. So you can control the concurrency setup for your futures by tuning the ExecutionContext
in which they run.
For instance, to implement the second strategy you can do something like
import scala.concurrent.ExecutionContext
import java.util.concurrent.Executors
import scala.concurrent.future
object Main extends App {
val ThreadCount = 10
implicit val executionContext = ExecutionContext.fromExecutor(Executors.newFixedThreadPool(ThreadCount))
val f = future {
println(s"Hello ! I'm running in an execution context with $ThreadCount threads")
}
}