`withTimeout` with a long duration keeps the `DefaultExecutor` thread alive for much longer than necessary about kotlinx.coroutines HOT 2 CLOSED

Yes, that's correct, once DefaultExecutor sees that it's supposed to run some code eventually, it will just go to sleep and won't wake up until either the time comes to run that code, or some new event arrives. KEEP_ALIVE_MS is not part of the public contract and isn't advertised anywhere, so it's just a part of our internal implementation, not something you can rely on.

If you have specific requirements for when DefaultExecutor should finish, please share them. Without specific use cases, we'd rather not wake DefaultExecutor up each time a task is removed from its queue: let it sleep in peace.

Also, if you are okay with relying on the internal implementation details, you can interrupt the DefaultExecutor so that it recognizes that it doesn't have any more work to do:

runBlocking { withTimeout(10.seconds) {} }
val time = measureTime {
    arrayOfNulls<Thread>(Thread.activeCount())
        .apply(Thread::enumerate)
        .find { it?.name == "kotlinx.coroutines.DefaultExecutor" }!!
        .apply {
            interrupt()
            join()
        }
}
println(time)

from kotlinx.coroutines.

This came up because 9a98eab changed timeout of runTest to 60 seconds, which caused the DefaultExecutor thread to far outlive the lifetime of each test case and it was caught by a leaked thread detector that some of our tests used. That thread should obviously have been exempt from the detector anyway so that wasn't a real problem, but I thought that maybe this behavior was unintentional after seeing that the thread was only supposed to live for one second.

we'd rather not wake DefaultExecutor up each time a task is removed from its queue: let it sleep in peace.

Fair enough. I'll just consider this an implementation quirk then. No real problems here.

from kotlinx.coroutines.