本文介绍了使用Scala Futures时,是否会将具有相同执行上下文的链接回调优化为同步调用?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

限时删除!!

Scala 2.10中新的Future会对异步调用动作的每个操作(包括mapfilter等)使用执行上下文.这是否意味着将始终通过执行上下文单独调用每个动作,或者当使用同一执行上下文链接多个转换/过滤器​​时,是否有可能优化此步骤?

The new Future in Scala 2.10 uses an execution context for every operation where an action is called asynchronously (including map, filter, etc). Does this mean that every action will always be called individually through the execution context, or is it possible that this step is optimized away when chaining multiple transformations/filters each using the same execution context?

即如果执行f.map(...).filter(...).map(...)且都具有相同的执行上下文,则此调用execute()是一次(因为它足够聪明以组成上述同步函数)还是三次?

I.e. if doing f.map(...).filter(...).map(...), all with the same execution context, will this call execute() once (because it's clever enough to compose a synchronous function from the above), or three times?

如果scala未来无法进行上述优化,那么是否有替代框架更适合于做上述工作的长链合成物?

If the scala future does not do the above optimization, is there an alternative framework better suited for long chained compositions that does do the above?

推荐答案

我无法提供任何明确说明实际情况的文档链接,但我们可以进行简单的实验来回答您的问题.

I cannot provide any link to documentation which will clearly state what will really happen, but we can conduct a simple experiment which will answer your question.

只需打开Scala REPL并粘贴以下代码:

Just open the Scala REPL and paste the following code:

import java.util.concurrent.Executors
import scala.concurrent._

implicit val ec = new ExecutionContext {
    val threadPool = Executors.newFixedThreadPool(1000);

    def execute(runnable: Runnable) {
        threadPool.submit(runnable)
        println("execute!")
    }

    def reportFailure(t: Throwable) {}
}

future { 1 } map(_ + 1) filter (_ > 0) map (_ + 2)

它将打印:

scala>未来{1}地图(_ + 1)过滤器(_> 0)地图(_ + 2)
执行!
执行!
执行!
执行!
res0:scala.concurrent.Future [Int] = scala.concurrent.impl.Promise$DefaultPromise@7ef3de76

scala> future { 1 } map(_ + 1) filter (_ > 0) map (_ + 2)
execute!
execute!
execute!
execute!
res0: scala.concurrent.Future[Int] = scala.concurrent.impl.Promise$DefaultPromise@7ef3de76

因此,您正在执行的每个操作都会调用execute(并且您可以在文档中查看,每个函数(例如map或filter)都将ExecutionContext作为隐式参数: http://www.scala-lang.org/api/2.10.6/#scala.concurrent.Future )

So execute is called for every single operation you are doing (and as you can check in the documentation each function like map or filter takes ExecutionContext as an implicit parameter: http://www.scala-lang.org/api/2.10.6/#scala.concurrent.Future)

如果您正在寻找其他框架,则应检查scalaz期货.我没有与他们的经验,但他们似乎是您想要的.检查此线程: https://groups.google.com/论坛/#!msg/scalaz/-PuakIf-g_4/7ydrU5VIfDQJ

If you are looking for an alternative framework you should check scalaz Futures. I have no experience with them, but they seems to be what you are looking for. Check this thread: https://groups.google.com/forum/#!msg/scalaz/-PuakIf-g_4/7ydrU5VIfDQJ

Future也与scala 2.10 Future类型不同,因为它不一定表示 running 计算.取而代之的是,我们使用scalaz.Nondeterminsm界面的功能明确地引入了不确定性 .这简化了我们的实现,并且使代码更易于推理,因为效果的顺序和不确定性的要点已完全明确,并且不依赖于Scala的评估顺序.

Future also differs from the scala 2.10 Future type in that it does not necessarily represent a running computation. Instead, we reintroduce nondeterminism explicitly using the functions of the scalaz.Nondeterminsm interface. This simplifies our implementation and makes code easier to reason about, since the order of effects and the points of nondeterminism are made fully explicit and do not depend on Scala's evaluation order.

重要说明:Future不包括任何错误处理,并且通常只应由希望基于Future功能构建但希望设计自己的错误处理策略的库编写者用作构建块.请参见scalaz.concurrent.Task以了解扩展Future并进行适当错误处理的类型-它只是Future[Either[Throwable,A]]的包装,具有许多其他便利功能.

IMPORTANT NOTE: Future does not include any error handling and should generally only be used as a building block by library writers who want to build on Future's capabilities but wish to design their own error handling strategy. See scalaz.concurrent.Task for a type that extends Future with proper error handling -- it is merely a wrapper for Future[Either[Throwable,A]] with a number of additional convenience functions.

这篇关于使用Scala Futures时,是否会将具有相同执行上下文的链接回调优化为同步调用?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

1403页,肝出来的..

09-06 22:26