scala.concurrent.Await#ready versus #await?

[Kevin Meredith]

scala.concurrent.Await's docs (http://www.scala-lang.org/api/2.11.8/#scala.concurrent.Await$) show 2 functions: await and ready.

await's docs:

Await the "completed" state of an Awaitable.

Although this method is blocking, the internal use of blocking ensures that the underlying ExecutionContext is prepared to properly manage the blocking.

ready's docs:

Await and return the result (of type T) of an Awaitable.

Although this method is blocking, the internal use of blocking ensures that the underlying ExecutionContext to properly detect blocking and ensure that there are no deadlocks.

Looking at the docs alone, it seems to me that `ready`'s difference is that it will "ensure that there are no deadlocks."

Can you please explain further the difference between the two? Why would I pick one over the other?

[Rex Kerr]

The docs show `ready` and `result`.  The former blocks until the awaitable is ready and gives you back the awaitable; the latter blocks until the awaitable is ready and gives you its contents.  The implementation is otherwise identical.

I'm not sure where you're finding `await`, but it's not in 2.10, 2.11, or 2.12's Await object.

  --Rex

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Viktor Klang]

That scaladoc is ripe for a makeover, it is indeed confusing.

the difference between *ready* and *result* is that one produces a result and the other just blocks until the Awaitable is ready…

--

Cheers,

√

[Kevin Meredith]

Thanks for the explanations, Rex and Viktor.

Per your response, Viktor, under what circumstances would you choose ready over result, and vice-versa?

[Viktor Klang]

On Tue, Nov 22, 2016 at 9:12 PM, Kevin Meredith <kevin.m....@gmail.com> wrote:

Thanks for the explanations, Rex and Viktor.

Per your response, Viktor, under what circumstances would you choose ready over result, and vice-versa?

You might have an Awaitable where assembling the result is costly, and in case you only wnat to establish a happens-before relationship `ready` is cheaper.

A sidenote is that Await was added to discourage its own usage.

So technically I'd advise you to try to come up with a solution which doesn't entail blocking. :)

 

On Tuesday, November 22, 2016 at 1:16:03 PM UTC-5, Kevin Meredith wrote:

scala.concurrent.Await's docs (http://www.scala-lang.org/api/2.11.8/#scala.concurrent.Await$) show 2 functions: await and ready.

await's docs:

Await the "completed" state of an Awaitable.

Although this method is blocking, the internal use of blocking ensures that the underlying ExecutionContext is prepared to properly manage the blocking.

ready's docs:

Await and return the result (of type T) of an Awaitable.

Although this method is blocking, the internal use of blocking ensures that the underlying ExecutionContext to properly detect blocking and ensure that there are no deadlocks.

Looking at the docs alone, it seems to me that `ready`'s difference is that it will "ensure that there are no deadlocks."

Can you please explain further the difference between the two? Why would I pick one over the other?

--

You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,

√

[Rex Kerr]

`ready` is good if you want to do error checking or you want to perform more steps but you need to manually synchronize things at this point for some reason.  If you just want the answer, and to throw an exception if something went wrong, choose `result`.

  --Rex

--