Dispatchers.IO defaults to being backed by an executor that can spawn up to 64 threads. Is it possible to architect an app with suspending non-blocking IO calls and we'd just use one thread for the IO dispatcher? Is it a reasonable expectation that migrating to coroutines+flow from rx will reduce the total number of threads an android application uses? This is the high-level question I am trying to answer.

Most likely no, because under the hood almost any low-level io operation is blocking (e.g. reading from file, establishing a http connection etc).

> Is it possible to architect an app with suspending non-blocking IO calls and we’d just use one thread for the IO dispatcher? Definitely, just create a single-threaded dispatcher and use that for IO instead of

<http://Dispatchers.IO|Dispatchers.IO>

But that means that if you try doing more than one IO operation at once, your app is just going to sit around doing nothing and waiting for the first operation to complete, which is not very efficient.

@bezrukov We should be able to do io non-blocking with nio, no? Okhttp and okio do not appear to make use of nio's non-blocking apis, so I see what you are saying @Zach Klippenstein (he/him) [MOD] I am looking at Http1ExchangeCodex for reference. I did some digging and it looks like ktor's http client may offer what I have in mind.

@Brendan Weinstein yes, using nio definitely makes sense