What do folks think about an unbounded io dispatch...
# coroutines
b
What do folks think about an unbounded io dispatcher/scheduler vs a bounded io dispatcher/scheduler? In Rx the io scheduler is by default unbounded. That's bitten me in the butt at least once before with an OOM that happened when a user with several thousand documents would open up the app on a new device and we'd fire off several thousand threads for several thousand sync tasks. The flip side is it is easier to have deadlock with a bounded scheduler (eg https://twitter.com/ZacSweers/status/1067166787458949120) The io dispatcher in kotlin coroutines defaults to an io dispatcher backed by 64 threads (https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/jvm/src/Dispatchers.kt#L102). I would think that limiting to some reasonable number n (ie 64) is better than an unbounded thread pool since thread allocations are expensive and you'll get hit with more GC when you have a high number of tasks queued in a short time frame. What do folks think is the sensible default taking into performance and deadlock risk?