A modern programming language that makes developers happier.

kotlinlang

Should I use `<http://Dispatchers.IO|Dispatchers.IO>` or `Dispatchers.Default` for drawing with canvas on a bunch of bitmaps (GIF frames)?

I'd say use `Dispatchers.Main` if you have it or `Dispatchers.Default`  if you don't. `<http://Dispatchers.IO|Dispatchers.IO>` is mainly reserved for blocking operations like reading files or fetching stuff over the network.

Using `Main` blocks the UI thread so I'd use `Default` . Thanks!

_Shouldn't_ it block it? Thought that'd be the expected behaviour since you're updating the UI.

I have a drawing screen where the user draws stuff on top of a GIF image. When the user is done, I launch a coroutine to extract the bitmaps from the GIF and draw on each bitmap whatever the user drew on the drawing screen. Meanwhile, I'm showing a progress bar until the drawing is done.

Ah, gotcha. Then you're right, avoid `Dispatchers.Main` for this.

`IO` is for work that blocks the thread, but doesn’t actually do any work on the CPU while blocking – IO calls block but they hand control over to the kernel and then just sit there idle until the kernel gives a result back. Since these threads just hold state but don’t actually _use_ the CPU while blocked, there can be many more active IO threads than CPU cores (i believe the default is 64). The only real limit here is memory and how many IO operations your OS can reasonably execute concurrently.

`Default` is for work that actually executes instructions on the CPU. Work dispatched to these threads actually requires a core to run on, so there are only roughly as many threads in the `Default` pool as there are cores/processors on a machine.

<@U0KMMQA20> I thought that, by default (on Android?), `<http://Dispatchers.IO|Dispatchers.IO>` and `Dispatchers.Default` share the same thread pool under the hood, so switching context between them can be efficient as stuff can likely run on the same thread or at least in the same pool. I imagine that only if running out of thread pool resources that these dispatchers will start using disjoint sets of threads, or thread pools. Am I (somewhat) right?

So, given your explanation and my (mis)understanding, what's the actual situation?

They do actually share the same threads, but it’s not like a normal thread pool. Threads in one dispatcher can effectively migrate to the other dispatcher when the coroutine they’re running becomes suspended on work scheduled to the other dispatcher. This is a technique to reduce context switching at the OS layer, since the same thread can stay active on the CPU.

But logically, the `Default` dispatcher will only use roughly the number of threads as you have cores/processors, and the `IO` dispatcher will be capped at a higher value (64).