Hi! I'm learning Coroutines and trying to wrap my head around how coroutines are run on a thread. So if I run large number of work-heavy coroutines on a thread, it will block that thread but if I run handful of them, there's a very small probability that the thread will be blocked. I'm trying to understand, how and why does coroutines block the thread in the former case and not in the latter one?

It's not as magic as it might look. 🙂 When a coroutine suspends, the thread it was running on can handle other tasks. When a coroutine resumes, it monopolizes that thread until it suspends again. If a coroutine never suspends or does a lot of work between suspend points, the thread it runs on will be occupied for that full time.

How are you verifying the thread is blocked / not blocked when running only a small number? Does this mean you see the thread idle when there is unfinished work that is supposed to run on them?

When a coroutine suspends

When a coroutine resumes

@Adam Powell What or who decide to perform these actions and when? Is it possible that our coroutine will not be resumed if the thread(say, the coroutine was launched on main thread) is rather busy?

yea I am not sure what that really proves, if you run a lot of work on a thread its going to be blocked/slower compared running less work. I assume this was a dedicated thread for each test that the UI was just waiting for it to complete, vs running on the UI thread?

When a coroutine suspends is determined by when some suspend function calls some variant of

suspendCoroutine

. That produces a

Continuation

object, which acts like a callback; when something else calls

resume

on it, the

ContinuationInterceptor

from the continuation's

CoroutineContext

is consulted for how to resume the continuation. Usually this is a

CoroutineDispatcher

, which acts like an

Executor

. The dispatcher is responsible for making sure continuations resume in the right thread.

So, conceptually I can run a network call in a coroutine launched on main thread and it will not lead to

NetworkOnMainThreadException

?

A coroutine is an abstraction of work to be done, like a wrapper for a task. Although its usually used with threads its not required

So the network call in a main thread coroutine(on Android) will not lead to an exception then, right?

as long as you use something like withContext(Dispatchers.IO) or a network library which handles the threading part for you like retrofit

When a coroutine resumes, it monopolizes that thread until it suspends again. If a coroutine never suspends or does a lot of work between suspend points, the thread it runs on will be occupied for that full time.

If a coroutine does not occupy a thread always, but is rather suspended and resumed, why do we need to switch to a different thread like

<http://Dispatchers.IO|Dispatchers.IO>

? I get that running a network call in a main thread coroutine will occupy the main thread for a long time, but still it can be done, right? What I understand right now is that moving over to the IO thread means that we just want to suspend the call on a IO thread

Network call cannot be done on the main thread simply because the Android OS doesn't allow it, most all other environments allow it with the side effect of the UI hanging until it finishes

Gotcha! What if we are doing some heavy work(not IO) in a main thread coroutine on Android, will that lead to Application Not Responding or UI hanging as described above?

Yes, the details on that I'm not sure of but its however android measures "heavy work" on the main thread. Network is simply not allowed even if it would have been relatively quick

Thanks guys! I think I've more clear understanding of coroutines now