runBlocking with Android's Main.immediate scheduler locks with other nested contexts

[dlew]

I've been trying to figure out why this code freezes on Android (when started on the main thread):

runBlocking {
  Log.i("test", "start runBlocking")
  withContext(Dispatchers.Main.immediate) {
    Log.i("test", "start Main.immediate context")
    withContext(Dispatchers.IO) {
      Log.i("test", "running IO context") // Prints
    }
    Log.i("test", "end Main.immediate context") // Never prints
  }
  Log.i("test", "end runBlocking") // Never prints
}

The inner context has to be something like Dispatchers.Default or Dispatchers.IO.

I've been able to track down where the code freezes: BlockingCoroutine.joinBlocking() eventually calls parkNanos(this, Long.MAX) and thus the code just stops. I don't understand coroutines well enough to understand how it got into this state, though.

This came up because it's easy to accidentally run into this situation when calling suspending functions that are using their own withContext() calls. E.g., you call runBlocking { someSuspendingFunction() }, not knowing that you're going to end up inside Main.immediate and then IO (resulting in a freeze).

[elizarov]

It freezes because you use runBlocking to block the main thread. It's called runBlocking because that is what it does -- block the thread. If you block the main thread, it freezes your UI.

Does it help?

[dlew]

I understand that part - I expect it to freeze the UI temporarily. However, the above code freezes the UI permanently, even though everything inside of it finishes execution.

In particular, somewhere within coroutines, it's choosing to wait park itself for 292 years (i.e. the parkNanos(this, Long.MAX) call) .

[elizarov]

Aha! Indeed, that's a bug. It even reproduces with a Swing main dispatcher with a pretty small self-contained reproducer:

import kotlinx.coroutines.*
import javax.swing.*

fun main() {
    SwingUtilities.invokeAndWait {
        runBlocking {
            println(1)
            withContext(Dispatchers.Main.immediate) {
                println(2)
                withContext(Dispatchers.IO) {
                    println(3)
                }
                println(4) // NOT REACHED
            }
            println(5)
        }
    }
}

[elizarov]

Here's what happens:

1. The main thread is blocked by runBlocking { ... }

2. The coroutines execution context is switched into Dispatchers.Main.immediate, which does not do anything since the execution is already in the main thread.

Note here, that if you try withContext(Dispatchers.Main) (non immediate) from inside of runBlocking, then it hangs, because the main thread is blocked and cannot execute a scheduled asynchronous task.

3. The execution context is switched into Dispatchers.IO

4. There is an attempt to switch from Dispatchers.IO to Dispatcher.Main but it deadlocks, because the main thread is blocked with runBlocking.

TL;DR: Don't block the main thread with runBlocking. It produces all sorts of weird stuff.

Can we somehow fix this particular case? It is not really clear. It is also not clear if we even should fix this particular case, since the fact that it does even hang at step 2 is already quite a miracle (a happy side effect of using an immediate variant of Dispatchers.Main).

[slavonnet]

This as i try catch in
#2374

[larssn]

So I ran into this in a Flutter plugin, which are always using the main thread by default.
So I use runBlocking to offload some work into non-ui threads which has worked great. However I ran into a scenario where one of these threads needs to report back to the main thread, which caused the hang.

Is there any workaround, or ideas?

[qwwdfsad]

The best solution would be not to use runBlocking, but rather regular coroutines (e.g. launch(Dispatcher.Main) {})

[slavonnet]

1. Why can't you define that the main thread is already blocked and just add a child? A link to the main coroutine can be stored in a variable local to the thread.

2. Why, if a thread is blocked for a long time, it is impossible to release it every X seconds to draw the interface?

3. Why do I need to block the main thread? Why can't an exception be made for the main android thread and work through a looper? Instead of blocking and waiting, you can perform the next task from the looper at this point.

Why do you rely on the looper as an android specific, but refuse the main dispatcher to fully adapt to the android specificity?

[zach-klippenstein]

You're basically just describing all the benefits of using coroutines without runBlocking as @qwwdfsad suggested. Coroutines are designed to work that way when used correctly on platforms like Android that have their own loopers. runBlocking is only intended for use when such infrastructure does not exist.