There should always be a single-threaded main dispatcher at run time

[zjuhasz]

There are many situations where having an entirely single threaded application or "mostly single threaded application" (application which primarily uses a single thread but which offloads intensive cpu bound tasks to workers, potentially returning deferred results) is desirable, particularly when using coroutines. Confining an applications core functionality (namely mutable state) to a single thread allows the developer to forget about thread safety issues.

Single threaded applications are currently supported by kotlinx.coroutines. When making an application with a GUI in a supported framework, the UI thread is used as the main dispatcher and when making a plain Java application you can create your own single thread dispatcher. For native, I think single threaded is the only option right now. Although some boiler plate could be removed by making suspend fun main() create a main dispatcher so one doesn't need to be created and used manually with fun main() = runBlocking(Dispatchers.MySingleThreadedDispatcher), it's not a major issue for application developers.

The place where there is a major problem is for library developers. I think there are many situations where library developers may want to take advantage of a guaranteed single threaded dispatcher. You have the classic simplest example of incrementing a counter from several coroutines; it's nice to be able to do this safely in a library without needing to worry about some atomic wrapper.
I will also provide a simplified version of my own current use case. I have a class in a library that can record certain types of data to disk for a given duration. Each stream of data you're recording has its own recorder which has a UID. The UID of a Recorder is global, and the previous one is used to determine the next one, already running into potential concurrency problems. Each recorder splits the recorded data from its stream into several files so it can clean up old data by deleting old files and adding / removing the files from a List as it goes. Each file has a coroutine that delays for a certain amount of time and then removes that file. We can read data back into memory by going through the files in the list (a shallow copy still needs to be made to avoid concurrent modification, the file class keeps track of if the file has been deleted so it's not an issue). Without a single threaded dispatcher I would either need to use locks or some actor model which I think is overkill for this task. It's a data acquisition and control library so it's far from guaranteed it will be run in an application with a GUI. Potentially it could just sit there in some embedded IoT application with no UI at all, graphical or command line. Right now the library actually has its own single threaded dispatcher which is sort of OK with one library but could be a problem if an application has 15 dependencies that all do this, not to mention there will likely end up being more context switching then there needs to be.
Sorry if this wall of text description isn't clear, I'll post the source code fairly soon, so everyone can see this exact use case in code.

Library developers cannot rely on Dispatchers.Main for the following reasons:

1. The documentation does not require it to be a single thread (although I believe all the currently supported implementations are).
2. It's not guaranteed to exist / have an implementation.

I think both of these things should be changed.

The first change is obvious, only single threaded dispatchers should be allowed to be the main dispatcher. Either that or there should be another standard dispatcher added which is always single threaded and in this case I do not think Dispatchers.Main should be declared in core.

And I think the second doesn't need to stray too far from the current behavior, there just need to be some steps added to establish a main dispatcher. I also think the default dispatcher should always be the main dispatcher.

1. If there is a MainCoroutineDispatcher implementation in the class path it is used (this is the current behavior I think, not sure what the conflict resolution mechanism is if there are multiple).
2. else if the main() function is suspend it creates a single threaded dispatcher and uses it as Dispatchers.Main as well as the thread that main is invoked on.
3. else there is a fallback main dispatcher that is used, primarily existing so libraries have a reliable single threaded dispatcher to use and don't need to create their own.

Of course there are many other ways but this comes to mind as a relatively simple update I think.

[fvasco]

Hi @zjuhasz
my concerns about your considerations it how to define a single thread for all not concurrent-safe operation, blocking and non blocking ones.
If this thread exists, you cannot assume this dispatcher inside your library, I encourage you to use withContext to ensure the right condition for your code.

Moreover I don't consider a Mutex or an actor a overkill, please consider the cost of a context switch (i.e. http:https://ithare.com/infographics-operation-costs-in-cpu-clock-cycles/).

Finally please consider #261

[zjuhasz]

how to define a single thread for all not concurrent-safe operation, blocking and non blocking ones

I meant only suspending operations, not blocking ones. For blocking operations you would still need to use the IO dispatcher. I said thread safe instead of concurrent safe because there are still concurrency issues you need to keep in mind. For example if there is a forEach loop on a collection that suspends on each element, you could get concurrent modification problems (this one actually comes up in my example).

please consider the cost of a context switch

Most of the operations I'm describing are completely internal to the library so there would be no context switching as everything would always be launched in the main dispatcher. If anything that uses the main dispatcher for thread safety is exposed in the api you would need to use withContext but it should rarely cause an actual context switch as the main dispatcher is the same in the library and the application. I could also switch suspend fun getData(): List<MyData> to fun getDataAsync(): Deferred<List<MyData>> = async(Dispatchers.Main) {} in which case there wouldn't be context switching even if it was called from another thread. Launching a coroutine from one context in another context isn't any more costly is it?

If this is deemed to risky we could say it should never be done and the main dispatcher should only be used for internal operations of a library, in this case I think #261 would achieve the same effect if I understand it correctly and would mostly solve my problem (although it looks like this is JVM only in which case it doesn't completely solve my problem). However I think there might be times when it is OK to expose an operation that relies on being executed in the main thread if the main thread is the same in the application and the library.

One of the things that made me consider this as a viable option is the concurrency model for kotlin/native. It looks like in kotlin/native the idea is you always have a "central thread" where state information is kept and only temporarily use a pool of workers for parallelized computations. If this pattern is established in kotlin then even exposed api calls which rely on doing things in the main dispatcher shouldn't result in an actual context switch if used correctly.

If it's decided that the main dispatcher should only be present in certain situations, why would it be declared in core?

[fvasco]

For example if there is a forEach loop on a collection that suspends on each element, you could get concurrent modification problems (this one actually comes up in my example).

I agree, this is independent by the thread amount.

#261 address your issue, however I consider the Mutex more appropriate (or both).

[elizarov]

@zjuhasz I think these are all good points:

The documentation does not require it to be a single thread (although I believe all the currently supported implementations are).

We can change that. Promising that the Main dispatcher is single-threaded seems reasonable.

It's not guaranteed to exist / have an implementation.

This is somewhat harder, but we can indeed have some fall-back behaviors for cases when no UI-specific Main dispatcher is present.

However, I would also strongly recommend considering other options for libraries writers as @fvasco pointed out:

• You can always create your library specific single-threaded dispatcher and use withContext(myDispatcher) { ... } in all your API methods.
• Consider using actor pattern in your library, e.g. instead of keeping a global state, confine to a single coroutine.

[dkhalanskyjb]

A common-code way to acquire a single-threaded dispatcher since 1.6.0-RC is https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-coroutine-dispatcher/limited-parallelism.html For example, Dispatchers.Default.limitedParallelism(1) does the trick: all tasks sent to it are serialized. This avoids a performance issue with creating one's own single-threaded dispatcher where each library would spawn its own thread and is very simple—just make sure to use the same dispatcher instead of calling limitedParallelism several times.

This still doesn't solve the problem where there is non-trivial threading behavior in data shared between different libraries, but, in my opinion, deciding to solve this by serializing everything would be incorrect: if at least something (another library, or just the user's application itself) decided not to use the common serialized state but do multi-threading, the threading problems would immediately surface. Seems error-prone. However, if I read this correctly, the issue is concerned with spawning some helper tasks in a serialized manner, not with the shared state, so limitedParallelism should do the trick nicely.