This message was deleted.

# coroutines

[Slackbot]

This message was deleted.

[voddan]

No. async will use the default dispatcher (thread pool) for it to run. runBlocking stays on the current thread

[Herko]

Correct, but the blocking effect on the thread async is called from will essentially be the same as runBlocking. Doing it with async will just incur more overhead? (in the context of the order of the calls as mentioned above)

[Herko]

I guess what I am trying to ask is, that there is no reason you would ever want to do a single async {...}.await() when .await follows the single async call directly, but rather just call runBlocking {...} in such a scenario?

[bj0]

no, runBlocking blocks the thread, .await suspends the thread, you never want to use runBlocking from a coroutine

[bj0]

*suspends the coroutine

[bj0]

you only use runBlocking from non-coroutines to launch and wait for a coroutine (or many) to finish

[Herko]

@bj0 you are correct, I see the documentation also warns against it.

[Herko]

Seems the case I am talking about it would make sense to have neither then, and call the inside of the block {...} directly.

[bj0]

true, the only reason to wrap something in an async with an immediate await is to change contexts (or suspend), but you can do that with withContext

[gildor]

withContext is much better choice if you just want to switch context: more efficient (no deferred instance), automatically connected to parent coroutine lifecycle and just more idiomatic

[gildor]

I don't know any case when you need async{}.await()