Почему Scala использует ForkJoinPool для возврата своего ExecutionContext по умолчанию?

В Scala вы можете использовать глобальный ExecutionContext, если вам не нужно определять свой собственный, импортируя scala.concurrent.ExecutionContext.Implicits.global.

Мой вопрос, почему ForkJoinPool был выбран для этого исполнителя вместо ThreadPoolExecutor.

Я понимаю, что структура fork-join превосходна при рекурсивном разложении проблем. Вы должны написать код, который разбивает задачу на половинки, так что половина может быть выполнена в потоке, а другая половина может быть выполнена другим потоком. Это кажется очень конкретной моделью программирования, а не той, которая обычно применима для обработки общих асинхронных задач в широком диапазоне возможных приложений.

Итак, почему был выбран ForkJoinPool для контекста исполнения по умолчанию, который, скорее всего, будет использовать большинство людей? Ухудшается ли дизайн вождения за счет повышения производительности, даже если вы не используете полную парадигму fork-join?

ОТВЕТЫ

Ответ 1

Я не могу говорить о конструкторах scala, но идиоматическое использование scala Future часто связано с созданием множества очень маленьких, непродолжительных задач (например, каждый вызов map создает новую задачу), и поэтому дизайн обработки работы является подходящим.

Если вам нужны эти точные данные, вы можете использовать scalaz-concurrent Future, который использует батуты, чтобы избежать создания дополнительных задач для каждого шага map и делает контексты выполнения явными (и AIUI по умолчанию имеет значение ThreadPoolExecutor).