Coroutines do 𝗡𝗢𝗧 automatically run computations in the background!

One worrying thing I’ve noticed during the recent interviews I’ve been conducting is devs thinking that starting a coroutine == starting a new thread.

Spoiler - they don’t.

So what's the confusion?

It seems like the maintainers of Room and Retrofit libraries have done such a good job of being good threading “citizens” that some developers have forgotten about threading altogether. I was today years old when I found out that you can call Retrofit and Room suspending functions straight from the main thread.

Devs these days don’t know how good they have it. Back in the old days, we had to use Async Tasks after walking 10 miles in the snow blizzard.

Anyway, I built this example to demonstrate what can happen when you run coroutines without specifying the dispatcher.

As I mentioned previously, it seems like people are forgetting we can have blocking functions in our code. Besides Retrofit and Room, there are still things like writing files to memory, data encryption, and image processing that are thread-blocking and don’t provide suspending APIs (not yet at least).

Many people asked me why I included 𝚃𝚑𝚛𝚎𝚊𝚍.𝚜𝚕𝚎𝚎𝚙() in the example. I did it specifically to demonstrate a blocking operation. If you don’t specify a dispatcher for your coroutine - it will run the blocking operation on the thread from which you invoked it. And this can stall your application. If this was a network request - we would get the infamous 𝙽𝚎𝚝𝚠𝚘𝚛𝚔𝙾𝚗𝙼𝚊𝚒𝚗𝚃𝚑𝚛𝚎𝚊𝚍𝙴𝚡𝚌𝚎𝚙𝚝𝚒𝚘𝚗 .

The main thing to remember here is that coroutines use threads. You’re not creating a thread when you’re launching a coroutine. Each newly created coroutine will run on the same thread as the previous coroutine (if you don’t specify otherwise). Even though coroutines run concurrently - you can still block the thread you’re running it on.

Everything inside a coroutine is executed sequentially. If the next operation in your coroutine is blocking (like 𝚃𝚑𝚛𝚎𝚊𝚍.𝚜𝚕𝚎𝚎𝚙()) - you will block the crap out of the underlying thread.

If you look at step #5 in the example - you see that the operations are executing “at the same time”. In step #5 both coroutines are running concurrently - so it’s up to the processor to decide which instruction will run next. But what we D͟O͟ know is that even if 𝚍𝚎𝚕𝚊𝚢(𝟻𝟶𝟶) runs first - it will “release” the thread and we’ll block it with 𝚃𝚑𝚛𝚎𝚊𝚍.𝚜𝚕𝚎𝚎𝚙() either way for a whole second.

So there you have it, folks. Remember that a coroutine is just a mechanism to manipulate threads - it’s the threads that do the heavy lifting - coroutines simply take all the glory.