I'm trying to understand issues I noticed in the Default Dispatcher. At one point, I know this was backed by a pool similar to CommonPool with only threads = CPUs, coerced to at least 2 threads. What is the pool size today on JVM? I ran into issues not long ago where our app had been deadlocking on dependent work using the Default Dispatcher, but the same issue did not occur if I migrated the misplaced IO-bound work off to the IO dispatcher. The issues would only occur on the 1% of devices with the fewest cores, but the deadlock would extend for the full five second ANR interval on Android before I made the change. It seems like Dispatchers.Default must have a size smaller than the IO Dispatcher. This seems because Dispatchers.Default is still intended for CPU-bound work, like CommonPool. Is that correct or am I off-base?

yes, the IO dispatcher has always been much larger, I think around 64/128 threads

Are referring to deadlock or ANR? Because ANR is only caused by blocking the main thread for more than 5 seconds, which has nothing to do with

Dispatchers.Default

.

A deadlock can cause an ANR, which seems very likely to be the case here. If there's a dependency between the work tasks to complete loading the app and too few threads because there are fewer CPUs, you get both. I'm asking specifically about how this Dispatcher changed. I know about CommonPool, but what are the threading properties of the new Dispatchers.Default?

@colintheshots "can". Not all deadlock can cause an ANR. If you're using blocking primitives like

synchronized

,

java.util.Lock

or

runBlocking

, sure you can have ANRs as a result, but otherwise, it's all suspending functions that don't prevent android.os.Handler from dispatching and running work.

Why would the ANR only happen on devices with two or four cores? I want to understand better how this dispatcher works.

@colintheshots Because most devices have 2 or 4 CPU cores? Anyway, you're very likely having some code using locking primitives as I said, and this might depend on the number of cores. If you want to understand how this works, looking at the source code would probably help, but that's very unlikely to fix your ANR as it's not using locking primitives AFAIK.