You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
importkotlinx.coroutines.*funmain() {
runBlocking {
launch(Dispatchers.Unconfined) {
println("Starting in ${Thread.currentThread()}")
delay(100)
println("Continuing in ${Thread.currentThread()}")
}
}
}
currently outputs
Starting in Thread[main @coroutine#2,5,main]
Continuing in Thread[kotlinx.coroutines.DefaultExecutor @coroutine#2,5,main]
DefaultExecutor is the thread backing the whole kotlinx.coroutines framework, and its availability is important for delays to work correctly. We shouldn't give it arbitrary tasks to execute if we can avoid it.
What should be instead?
Before the delay, the Unconfined dispatcher uses the event loop created by runBlocking to execute its tasks. That event loop is also a delay, so delay(100) could execute in runBlocking as well, which would mean the unconfined task would be resumed in that same event loop, not bothering the DefaultExecutor.
Why?
Improved availability of DefaultExecutor could decrease the latency of resumption of tasks after delay in some scenarios.
Why not?
We haven't actually seen this being a problem in the wild: Dispatchers.Unconfined rarely needs to call delay, just by the nature of the tasks typically executing in it. Also, in the cases where it does happen, this could be a breaking change.
The text was updated successfully, but these errors were encountered:
What do we have now?
currently outputs
DefaultExecutor
is the thread backing the whole kotlinx.coroutines framework, and its availability is important fordelay
s to work correctly. We shouldn't give it arbitrary tasks to execute if we can avoid it.What should be instead?
Before the
delay
, theUnconfined
dispatcher uses the event loop created byrunBlocking
to execute its tasks. That event loop is also adelay
, sodelay(100)
could execute inrunBlocking
as well, which would mean the unconfined task would be resumed in that same event loop, not bothering theDefaultExecutor
.Why?
Improved availability of
DefaultExecutor
could decrease the latency of resumption of tasks afterdelay
in some scenarios.Why not?
We haven't actually seen this being a problem in the wild:
Dispatchers.Unconfined
rarely needs to calldelay
, just by the nature of the tasks typically executing in it. Also, in the cases where it does happen, this could be a breaking change.The text was updated successfully, but these errors were encountered: