Mark Murphy

There are four main dispatchers (or sources of dispatchers) that you will find yourself using… if you are working in Kotlin/JVM.

If you do not provide a dispatcher to the stock implementations of launch() or async(), your dispatcher will be Dispatchers.Default. This dispatcher is for generic background work.

Dispatchers.IO. This is designed for background work that may potentially block, such as disk I/O or network I/O.

In Kotlin/JVM, this dispatcher does not have its own thread pool. Instead, it shares a thread pool with Dispatchers.Default. However, Dispatchers.IO has different logic at the level of the dispatcher for using that thread pool, taking into account the limited actual parallelism that may be going on due to the blocking nature of the work.

Dispatchers.Main exists for UI work. In some environments, there is a “magic thread” that you need to use for such UI work. Dispatchers.Main will run its coroutines on that magic thread.

Dispatchers.Unconfined object. This is a dispatcher that does not use a separate thread. Instead, its behavior is somewhat unpredictable, as your coroutine will execute on different threads depending on the other dispatchers used in your code. As the documentation indicates, Dispatchers.Unconfined “should not be normally used in code”.

Coroutine builders have a default dispatcher.

However, you may not necessarily know what the default is for a coroutine builder for a particular CoroutineScope. For example, you have to rummage through the Android SDK documentation to discover that some of their custom CoroutineScope objects, such as viewModelScope on a ViewModel, use Dispatchers.Main as the default dispatcher.

All else being equal, it is safest — and most self-documenting — to declare your dispatcher for your coroutine builders.

The lambda expression supplied to launch() runs asynchronously with respect to the caller, even if the caller is on the thread identified by the dispatcher that you provided to launch().

Android developers can think of launch(Dispatchers.Main) as being a bit like post() on Handler or View. Those methods take a Runnable and add it to the work queue for the main application thread. So, even if you are on the main application thread when you call post(), your Runnable is still run later, not immediately. Similarly, the coroutine specified by launch(Dispatchers.Main) is run later, not immediately.

There is a specialized dispatcher, Dispatchers.Main.immediate, that may be available in your environment. If the caller happens to be on the main application thread at the time of launching the coroutine, the coroutine is executed immediately, rather than being put into a bucket of coroutines to run later.