Default delay behavior on Android creates additional threads when using external dispatchers
#2972
Labels
Comments
|
Indeed, we could design & implement a pluggable implementation for a default delay mechanism that |
qwwdfsad
added a commit
that referenced
this issue
Oct 11, 2021
It reduces the number of redundant threads in the system and makes time source predictable across Android/JavaFx applications Fixes #2972
qwwdfsad
added a commit
that referenced
this issue
Nov 17, 2021
It reduces the number of redundant threads in the system and makes time source predictable across Android/JavaFx applications Fixes #2972
qwwdfsad
added a commit
that referenced
this issue
Nov 17, 2021
It reduces the number of redundant threads in the system and makes time source predictable across Android/JavaFx applications Fixes #2972
|
To opt-out from this behaviour, a temporary system property |
|
Shouldn't variables declarations be swapped? See #3044. internal actual val DefaultDelay: Delay = initializeDefaultDelay()
private val defaultMainDelayOptIn = systemProp("kotlinx.coroutines.main.delay", true)
private fun initializeDefaultDelay(): Delay {
// Opt-out flag
if (!defaultMainDelayOptIn) return DefaultExecutor
...
} |
|
Right, this is the bug with the cyclic initialization |
qwwdfsad
added a commit
that referenced
this issue
Jan 11, 2022
The approach from 1.6.0 has proven itself as unstable and multiple hard-to-understand bugs have been reported:
* JavaFx timer doesn't really work outside the main thread
* The frequent initialization pattern "runBlocking { doSomethingThatMayCallDelay() }" used on the main thread during startup now silently deadlocks
* The latter issue was reported both by Android and internal JB Compose users
* The provided workaround with system property completely switches off the desired behaviour that e.g. Compose may rely on, potentially introducing new sources of invalid behaviour
The original benefits does not outweigh these pitfalls, so the decision is to revert this changes in the minor release
Fixes #3113
Fixes #3106
qwwdfsad
added a commit
that referenced
this issue
Jan 17, 2022
The approach from 1.6.0 has proven itself as unstable and multiple hard-to-understand bugs have been reported:
* JavaFx timer doesn't really work outside the main thread
* The frequent initialization pattern "runBlocking { doSomethingThatMayCallDelay() }" used on the main thread during startup now silently deadlocks
* The latter issue was reported both by Android and internal JB Compose users
* The provided workaround with system property completely switches off the desired behaviour that e.g. Compose may rely on, potentially introducing new sources of invalid behaviour
The original benefits does not outweigh these pitfalls, so the decision is to revert this changes in the minor release
Fixes #3113
Fixes #3106
|
We decided to revert this change in In the meantime, we have to find another solution for this problem |
yorickhenning
pushed a commit
to yorickhenning/kotlinx.coroutines
that referenced
this issue
Jan 28, 2022
…#2974) * Use Dispatchers.Main as default delay source where applicable It reduces the number of redundant threads in the system and makes time source predictable across Android/JavaFx applications Fixes Kotlin#2972
yorickhenning
pushed a commit
to yorickhenning/kotlinx.coroutines
that referenced
this issue
Jan 28, 2022
…tlin#3131) The approach from 1.6.0 has proven itself as unstable and multiple hard-to-understand bugs have been reported: * JavaFx timer doesn't really work outside the main thread * The frequent initialization pattern "runBlocking { doSomethingThatMayCallDelay() }" used on the main thread during startup now silently deadlocks * The latter issue was reported both by Android and internal JB Compose users * The provided workaround with system property completely switches off the desired behaviour that e.g. Compose may rely on, potentially introducing new sources of invalid behaviour The original benefits does not outweigh these pitfalls, so the decision is to revert this changes in the minor release Fixes Kotlin#3113 Fixes Kotlin#3106
dee-tree
pushed a commit
to dee-tree/kotlinx.coroutines
that referenced
this issue
Jul 21, 2022
…tlin#3131) The approach from 1.6.0 has proven itself as unstable and multiple hard-to-understand bugs have been reported: * JavaFx timer doesn't really work outside the main thread * The frequent initialization pattern "runBlocking { doSomethingThatMayCallDelay() }" used on the main thread during startup now silently deadlocks * The latter issue was reported both by Android and internal JB Compose users * The provided workaround with system property completely switches off the desired behaviour that e.g. Compose may rely on, potentially introducing new sources of invalid behaviour The original benefits does not outweigh these pitfalls, so the decision is to revert this changes in the minor release Fixes Kotlin#3113 Fixes Kotlin#3106
pablobaxter
pushed a commit
to pablobaxter/kotlinx.coroutines
that referenced
this issue
Sep 14, 2022
…#2974) * Use Dispatchers.Main as default delay source where applicable It reduces the number of redundant threads in the system and makes time source predictable across Android/JavaFx applications Fixes Kotlin#2972
pablobaxter
pushed a commit
to pablobaxter/kotlinx.coroutines
that referenced
this issue
Sep 14, 2022
…tlin#3131) The approach from 1.6.0 has proven itself as unstable and multiple hard-to-understand bugs have been reported: * JavaFx timer doesn't really work outside the main thread * The frequent initialization pattern "runBlocking { doSomethingThatMayCallDelay() }" used on the main thread during startup now silently deadlocks * The latter issue was reported both by Android and internal JB Compose users * The provided workaround with system property completely switches off the desired behaviour that e.g. Compose may rely on, potentially introducing new sources of invalid behaviour The original benefits does not outweigh these pitfalls, so the decision is to revert this changes in the minor release Fixes Kotlin#3113 Fixes Kotlin#3106
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When
delayis called using an externally-defined dispatcher that does not implement the internalDelayinterface, it uses a default fallback implementation that can cause an additional thread to be created. Some Android apps strictly audit threads created by their library dependencies and have raised this as an issue when using Jetpack Compose, which defines its own UI dispatcher and both promotes using thedelayAPI and uses it internally.On Android, apps always have a main thread running an event loop that could be used in place of creating an additional thread to time the
delay, which could makeDispatchers.Maina suitable choice for performing the default delay on Android when a compatible/known dispatcher is not found.The text was updated successfully, but these errors were encountered: