Blocking code wrapped inside Akka Future also blocks the thread backed by Future, then how is future helpful in this case

Question

The philosophy behind Akka/Scala Future is that when ever we find a blocking piece of code such as IO call , network call etc we have to wrap it up inside a future and asynchronously get the result after some point of time. But, the blocking piece of code that was blocking the main thread earlier is now blocking in the separate thread that Future is backed by. then what did Akka/Scala Future buy us.

val blockingCallResult: Result = block() //blocks the thread of execution.

now let's use Akka/Scala future and wrap the blocking call with Future


val future = Future[Result] {

   val blockingCallResult: Result = block() //also blocks on some thread in thread pool

   blockingCallResult

}

How are we getting benefited by using the future.

At this point the motivation for this question is unclear. Have you really been told that the only advantage of a Future is worker spawning? Have you taken a look at the Future API? — mikołak
@TheTerribleSwiftTomato ...Am a newbie to all these concepts . Please help me and correct me in case I sound like "stupid". anyways is it not something Future offers ? am still not able to understand, How future handles blocking calls to make it non blocking and avoid waiting, blocking because if future is backed by the thread poll then some or the other thread as to get blocked while doing IO calls (unless IO is non blocking like the one offered by Akka). is it not true ?. Why do we say Future helps in making code Non blocking instead of saying asynchronous only. — pamu
no, you don't sound stupid, asking questions about basic concepts is a completely valid (if under-utilized) way to progress. At this moment, to answer, I would like to ask you to provide sources to the statements you now referenced. This will allow me (or someone else) to view the questions in the context of those sources. — mikołak

lmm lmm · Accepted Answer · 2014-10-24T21:25:14

If you only have a single execution context, and you only use futures that execute blocking code, and only one at a time, then there is indeed no advantage from using a future. Advantages of futures are:

Parallelism - on a multicore machine, several threads can execute at the same time. Using futures with an execution context avoids the overhead of creating a new thread for every action or manually reusing threads, and the execution context gives you control over the pool size.
Separation of I/O and compute threads, by using different execution contexts. This allows the kernel to schedule interactive responses to I/O ahead of long-running computational tasks, improving latency.
True async I/O, via e.g. scala-redis-nb (or Netty or ReactiveMongo(?)). Rather than a Future just being a thread that blocks, it's possible to expose an async API (the kind that might otherwise use callbacks) using Futures (e.g. via Promises), and then you can write truly async code that avoids having any threads blocked on I/O, and with a much nicer API than using a callback-based API directly.

Blocking code wrapped inside Akka Future also blocks the thread backed by Future, then how is future helpful in this case

2 Answers