Right now there is only a Main dispatcher for GUI frameworks as far as I know. Has there been any discussion of always having a Main dispatcher? It's a really effective pattern (particularly when using coroutines) to only have one thread, even for non-ui applications. It allows you to completely forget about any thread safety problems in all cases except when there is some heavy cpu bound tasks that need to be parralelised. It also looks like the concept of always having a central thread is now baked into kotlin/native. In a vanilla jvm or native app

suspend fun main()

could start a single threaded dispatcher which would be the main dispatcher. You can make your own single threaded dispatcher for applications but it's a problem for libraries. Libraries can't safely use

Dispatchers.Main

because there is no gaurentee there will be an implementation in a users application. A library developer could require there to be an implementation of Dispatcher.Main meaning that if the user wasn't making a UI app they would have to provide their own implementation, but that seems to go against the docs. Also the documentation doesn't even say the main dispatcher must be single threaded, so it couldn't really be used as a home for operations that aren't thread safe anyway.

You are welcome to open an issue about that on https://github.com/Kotlin/kotlinx.coroutines/issues All you points are good, we are just still thinking of how exactly it should be addressed for non-UI applications. It would be great if you share some actual use-cases for non UI apps using a single-threaded Main dispatcher.

Thanks, I will open an issue

Thanks!