Dispatchers.IO not available on Kotlin/Native

[charleskorn]

Dispatchers.IO is only available for Kotlin/JVM according to the docs.

It would be great to have this available on Kotlin/Native, as this would make it easier to share code between JVM and native environments.

(from https://youtrack.jetbrains.com/issue/KT-51449)

[jakobkmar]

What is the best dispatcher to use for blocking IO operations on Kotlin/Native until this issue is resolved?

[qwwdfsad]

@jakobkmar newFixedThreadPoolContext with high enough number of threads (50-200) should do the trick

[Thomas-Vos]

Is there a way to create some sort of IO dispatcher with no thread switching from Dispatchers.Default? An IO dispatcher would be very helpful to me.

[saket]

@qwwdfsad wouldn't Dispatchers.Default be a better candidate because it uses dispatch_get_global_queue on native, whose thread count is auto-controlled by the system?

[dkhalanskyjb]

@saket we don't want Dispatchers.IO to share the behavior of Dispatchers.Default though, as the number of threads dedicated to I/O work (Dispatchers.IO) is typically an order of magnitude higher than the number of threads dedicated to doing work on the CPU (Dispatchers.Default). The reason is, many of those I/O threads most of the time will be doing nothing but waiting for some I/O operation to complete, so having many such threads will not overwhelm the system, whereas having many computation-heavy threads is undesirable: the computer can't physically perform more computations in parallel than it has CPU cores, so having much more threads dedicated to that can lead to a slowdown due to needless context-switching between threads.

[saket]

@dkhalanskyjb is your concern valid for both native and JVM platforms? I was only suggesting using Dispatchers.Default on native where it isn't limited to one thread per core.

[dkhalanskyjb]

is your concern valid for both native and JVM platforms?

Sure, I don't see any difference in this regard.

[vicpinm]

It's been almost a year since this issue was opened. Is there any update on this?

[jflavio11]

Hi Hi 👋 Flavio here

I've created an expect for this

expect class DispatcherProvider {
    ...
    fun io(): CoroutineDispatcher
    ...
}

And the implementation for the iOS module is:

actual class DispatcherProvider {
    actual fun io(): CoroutineDispatcher {
        return newFixedThreadPoolContext(nThreads = 200, name = "IO")
    }
}

However, I'm not pretty sure that the nThreads parameter should be passed as an arbitrary value. The Android IO Dispatcher implementation is based on the number of available processors of the device:

// Dispatcher.kt →  DefaultIoScheduler
systemProp(
            IO_PARALLELISM_PROPERTY_NAME,
            64.coerceAtLeast(AVAILABLE_PROCESSORS)
)

Shouldn't we have something similar for iOS? Limiting the nThreads by a number supported by the device's processor. Or maybe is something that I'm missing?

[arkivanov]

Wondering, is it now available? The doc looks outdated? https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-dispatchers/-i-o.html

[jeffdgr8]

@arkivanov yeah, it's an extension function that shadows the JVM field, documented here: https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-i-o.html