multithreading - Why does Scala use a ForkJoinPool to back its default ExecutionContext? -

in scala can use global executioncontext if don't need define own importing scala.concurrent.executioncontext.implicits.global.

my question why forkjoinpool chosen executor instead of threadpoolexecutor.

my understanding fork-join framework excellent @ recursively decomposing problems. you're supposed write code breaks task halves, half can executed in-thread , other half can executed thread. seems particular programming model , not 1 applicable handling execution of general asynchronous tasks across wide range of possible applications.

so why forkjoinpool chosen default execution context people use? work-stealing design result in improved performance if don't use full fork-join paradigm?

i can't speak scala designers, idiomatic use of scala futures involves creation of lot of small, short-lived tasks (e.g. every map call creates new task) , work-stealing design appropriate.

if care these kind of precise details might prefer use scalaz-concurrent's future, uses trampolines avoid creating tasks each map step , makes execution contexts explicit (and aiui defaults threadpoolexecutor).