Alexandru Nedelcu

04/23/2023, 5:11 PM
Hi all, I'm learning about coroutines, and I chased a bug, which wasn't a bug, behaviour being caused by
being a limited thread-pool, which is odd. Sample: Normally,
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?


04/23/2023, 6:18 PM
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


04/23/2023, 10:09 PM
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


04/24/2023, 6:12 AM
If you’re only targeting the JVM, you can also lift a custom
into a dispatcher. More details:

Dmitry Khalanskiy [JB]

04/24/2023, 10:08 AM
Hi! 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