Я понимаю "ExecutionContext - это как таракан" :
Мы не можем говорить о Futures, не говоря о его ExecutionContext: они образуют дуэт (к сожалению) ..Это означает, что ExecutionContext был определен на ранней стадии (как правило, при запуске) и поэтому исправлен.Но вызывающие абоненты должны быть в состоянии решить, какой ExecutionContext они хотят запустить вашу функцию (например, используя свои собственные).Служба вызывающего абонента не несет ответственности за ее принудительное выполнение (за исключением исключений).
, и мы должны передать ее во время построения в качестве неявного аргумента
object Future {
def apply[T](body: =>T)(implicit executor: ExecutionContext)
}
, и если мыЧтобы иметь полный контроль над тем, в каком пуле потоков выполняется задача, мы должны использовать библиотеки, такие как cats-effect.
Тем не менее, мне было интересно, есть ли вообще какой-нибудь способ, которым мы могли бы взломать инициализированную lazy Future чтобы он работал в другом контексте выполнения, чем тот, с которым он был инициализирован?Возможно, какая-то отвратительная отражающая черная магия, где мы каким-то образом идентифицируем задачу и крадем ее из очереди, в которую она была помещена?
Например, скажем, у нас есть функция, которая принимает передачу по имени Future
def foo(f: => Future) = {
val differentExecutionContext = ExecutionContext.fromExecutor(...
/* run f on differentExecutionContext */
}
foo(Future(42)(ExecutionContext.Implicits.global))
Теперь то, что мы могли бы сделать, это использовать на сайте вызова другой контекст выполнения, как, например,
val differentExecutionContext = ExecutionContext.fromExecutor(...
foo(Future(42)(differentExecutionContext))
, однако это заставляет пользователя не забывать предоставлять и использовать другой контекст выполнения.Есть ли способ, которым Future(42) может работать на differentExecutionContext внутри foo вместо global, прозрачно для пользователя?
В случае, если это проблема XY, здесь контекст .