Hi all, I'm learning about coroutines, and I chased a bug, which wasn't a bug, behaviour being caused by

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

being a limited thread-pool, which is odd. Sample: https://gist.github.com/alexandru/e8ea5e728d77afde4f662b1f7a15ae78 Normally,

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

should be unlimited, if its destination is blocking I/O. This is because, as in the sample, you can end up with thread-starvation, i.e., a situation in which some threads try to wait for something to happen, but it never does, because there are no threads left to execute whatever it is that's waited on. So why is it limited, and how can it be configured to be unlimited?

I think it's just an intentional choice to prevent overusing resources You can configure max threads count using system property, see corresponding dispatchera doc https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-i-o_-p-a-r-a-l-l-e-l-i-s-m_-p-r-o-p-e-r-t-y_-n-a-m-e.html

If that pool was unlimited, your limit would be the memory, and you'd get OOMs instead of thread starvation. Not sure it would be an improvement. Either way you have a problem, so you may as well fix the root issue instead of allowing more (or "infinite") threads

If you’re only targeting the JVM, you can also lift a custom

ExecutorService

into a dispatcher. More details: https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/as-coroutine-dispatcher.html

Hi! https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-dispatchers/-i-o.html This piece of documentation gives most of the answers you seek. • You probably don't want unlimited threads. There is usually a sensible upper bound on their number. If you do, you can create

val unlimitedIoDispatcher = <http://Dispatchers.IO|Dispatchers.IO>.limitedParallelism(Int.MAX_VALUE)

and use that throughout instead. • The recommended approach is to consider the number of threads dedicated to various groups of tasks. At most, a hundred threads for DB connections, 10 threads for file reads, etc. Then, create views with the corresponding numbers of threads using

limitedParallelism

.