2

Someone can explain me why the behavior of Twitter future is not Async? Having this code

  private val future: Future[String] = Future {
    Thread.sleep(2000)
    println(s"Running this effect in ${Thread.currentThread().getName}")
    "Hello from Twitter"
  }

  println("Present")
  Await.result(future)

The output after two seconds is this one

Running this effect in main
Present

So the future is blocking and not running in another Thread

paul
  • 12,873
  • 23
  • 91
  • 153

1 Answers1

7

Twitter futures have somewhat different semantics from "standard" futures in scala.

Future.apply is actually analogous to standard scala's Future.successful: it creates a Future that is already satisfied – so, the block you pass in is executed immediately.

With Twitter Futures, you don't need the annoying ExecutionContext that you have to drag implicitly everywhere. Instead, you have a FuturePool to which you hand code explicitly to be asynchronously executed. E.g.:

    val pool = FuturePool.unboundedPool
    val future: Future[String] = pool {     
        Thread.sleep(2000)
        println(s"Running this effect in ${Thread.currentThread().getName}")
        "Hello from Twitter"
    }

The good thing about this is that, unlike scala.concurrent, this Future is self-contained: it "knows" about the pool managing it, so, you don't need to carry it around everywhere this Future goes in case someone will need to do map or flatMap or some other transformation on it.

Dima
  • 39,570
  • 6
  • 44
  • 70
  • On the other hand, I'd argue that it's the requester of the transformation that generally best knows which threadpool is more suited to executing the transformation (e.g. is it blocking, is it going to occupy the CPU for a long time, is it so short (in Scala 2.13) we should parasitically execute it) – Levi Ramsey Jun 15 '21 at 11:07
  • @LeviRamsey well, the requester still has the power to use a different pool _if it actually makes sense_. From my experience though, 99% of use cases don't require that (and, maybe 87% of devs who are just trying to `.onComplete(logInfo)` would do it wrong anyway if they had to choose the right pool every time), and dragging the EC with you everywhere is extremely annoying. – Dima Jun 15 '21 at 11:11
  • 1
    Akka Futures (Way back on Akka 1.x) used to have the "ExecutionContext" (then MessageDispatcher) embedded in the Future instance: https://github.com/akka/akka/blob/v1.3.1/akka-actor/src/main/scala/akka/dispatch/Future.scala#L822 The experience of doing that led to discarding that approach and move to the approach adopted when proposing SIP-14. – Viktor Klang Jun 16 '21 at 19:43
  • Not knowing what logic will get executed on "your" thread-pool makes it neigh impossible to do sane lifecycle management of a thread pool, and makes it really hard to reason about what gets executed where. If there was a way of doing reduction counting and avoiding OS-level blocking cheaply, then there would no longer really be any need for more than a single "thread pool"—which would be a true solution to the problem—which is thread management in the presence of starvation and/or OS-level blocking. – Viktor Klang Jun 16 '21 at 19:47
  • 1
    Alas, those (reduction counting, and avoiding OS-level blocking on the JVM) are not really feasible for me (or most other developers in the world) to solve, so what can be offered is a way of minimizing the negative impact imposed by unfairness and blocking. – Viktor Klang Jun 16 '21 at 19:49
  • @ViktorKlang Not defending it, just explaining. There are pros and cons to everything. Envy your awareness about what "most other developers in the world", and don't dispute it, but I do personally know many (albeit, certainly, not most in world) developers (at Twitter in particular), who would disagree with some of your blanket assertions and assumptions. – Dima Jun 16 '21 at 20:09
  • @Dima Apologies if that came across as being defensive, I intended to provide some context & backstory. It's always trade-offs all the way down, but some trade less for more than others. :) – Viktor Klang Jun 16 '21 at 20:34