Hi, I’m just learning about Coroutines and wanted ...

# coroutines

[Niklas]

Hi, I’m just learning about Coroutines and wanted to ask what effects the <http://Dispatchers.IO|Dispatchers.IO> has on iOS? Is it also backed by a global queue like Dispatchers.Default which is mentioned here: https://kotlinlang.org/docs/native-migration-guide.html#update-dependencies ? Unfortunately I can’t find any information about this and in the code I only see that the DefaultIoScheduler is being used for <http://Dispatchers.IO|Dispatchers.IO>. To be honest, I don’t know exactly what it does.

[Daniel Pitts]

I don't have a concrete answer for you, but the intent is simply that any blocking IO operations you have should be dispatched with the <http://Dispatchers.IO|Dispatchers.IO> . If you don't, you run the risk for blocking threads that are expecting to run in a non-blocking manner.

[uli]

Does Dispatchers.IO even exist on iOS? I have been painfully missing it, but it has also been a while since I checked.

[Niklas]

I don't really know. When I use <http://Dispatchers.IO|Dispatchers.IO> and run the iOS app, everything seems to work fine and it doesn't seem to run on the main thread. But I can't find any information on how this works.

[uli]

Do you know how it works on Android? I’d assume behaviour should be the same then.

[uli]

There is misleading documentation here about JVM only:
https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-dispatchers/-i-o.html
But in this ticket, I learned, that there is an extension for native:
https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-i-o.html

[Niklas]

Thanks for the links :) Do you know what that means that there is an extension?

I’ve tried a bit and get the following output from this code snippet

launch(Dispatchers.Main) {
    println("Main: $currentThread")
}
launch(Dispatchers.Default) {
    println("Default: $currentThread")
}
launch(<http://Dispatchers.IO|Dispatchers.IO>) {
    println("IO: $currentThread")
}
launch(newSingleThreadContext("MyOwnThread")) {
    println("MyOwnThread: $currentThread")
}

iOS:

IO: <NSThread: 0x2800dd100>{number = 10, name = (null)}
Default: <NSThread: 0x2800d5280>{number = 11, name = (null)}
MyOwnThread: <NSThread: 0x2800b1280>{number = 12, name = (null)}
Main: <_NSMainThread: 0x2800b4040>{number = 1, name = main}

Android:

IO: DefaultDispatcher-worker-5
Default: DefaultDispatcher-worker-5
MyOwnThread: MyOwnThread
Main: main

Seems so that on iOS different background thread are created and on Android these are reused for IO and Default.

[uli]

I don't know about iOS. But yes, Android shares a thread pool. And has another important optimization. If a coroutine switches context from default and io or the other way around, it stays on the same native thread if the concurrency limit allows. Saving an expensive, native context switch. Seems that iOS is not there yet.

[Niklas]

I have also just tested how this works with withContext. Apparently it is always executed on the same background thread on iOS for the respective dispatcher and switched on Android if necessary.

withContext(Dispatchers.Default) {
    println("Default 1: $currentThread")
}
withContext(Dispatchers.Default) {
    println("Default 2: $currentThread")
}
withContext(Dispatchers.IO) {
    println("IO 1: $currentThread")
}
withContext(Dispatchers.IO) {
    println("IO 2: $currentThread")
}
withContext(Dispatchers.IO) {
    println("IO 3: $currentThread")
}

iOS:

Default 1: <NSThread: 0x282b05080>{number = 4, name = (null)}
Default 2: <NSThread: 0x282b05080>{number = 4, name = (null)}
IO 1: <NSThread: 0x282be8280>{number = 9, name = (null)}
IO 2: <NSThread: 0x282be8280>{number = 9, name = (null)}
IO 3: <NSThread: 0x282be8280>{number = 9, name = (null)}

Android:

Default 1: DefaultDispatcher-worker-9
Default 2: DefaultDispatcher-worker-9
IO 1: DefaultDispatcher-worker-9
IO 2: DefaultDispatcher-worker-3
IO 3: DefaultDispatcher-worker-4

[Daniel Pitts]

Interesting. What about if you launch several async and add a small delay? It could be that iOS is smart enough to complete the work immediately and then reuse the thread.

[uli]

please wrap the whole block into withContext{Disptachers.Default) to see how switching between those Dispatchers works.

withContext(Dispatchers.Default) {
  withContext(Dispatchers.Default) {    
    println("Default 1: $currentThread")
  }
  withContext(Dispatchers.Default) {
    println("Default 2: $currentThread")
  }
  withContext(Dispatchers.IO) {
    println("IO 1: $currentThread")
  }
  withContext(Dispatchers.IO) {
    println("IO 2: $currentThread")
  }
  withContext(Dispatchers.IO) {
    println("IO 3: $currentThread")
  }
}

Or nest them:

withContext(Dispatchers.Default) {
  println("Default 1: $currentThread")
  withContext(Dispatchers.Default) {
    println("Default 2: $currentThread")
    withContext(Dispatchers.IO) {
      println("IO 1: $currentThread")
      withContext(Dispatchers.IO) {
        println("IO 2: $currentThread")
        withContext(Dispatchers.IO) {
          println("IO 3: $currentThread")
        }
      }
    }
  }
}

What’s happening with your test setup is probably, that you switch back to the surrounding dispatchers thread between each withContext.

[uli]

When you switch context each time from, let’s say main or runBlocking-dispatcher to a background dispatcher, it does not really make a difference, which background thread you schedule to

[uli]

On android, both variants of above code should run sequentially on a single thread without context switch.

[Niklas]

@Daniel Pitts If I’m using async it behaves as follows, regardless of whether there are delays between them or not:

async Default 1: <NSThread: 0x600001708800>{number = 7, name = (null)}
async Default 2: <NSThread: 0x600001708800>{number = 7, name = (null)}
async Default 3: <NSThread: 0x600001708800>{number = 7, name = (null)}
async IO 1: <NSThread: 0x6000017342c0>{number = 8, name = (null)}
async IO 2: <NSThread: 0x6000017342c0>{number = 8, name = (null)}
async IO 3: <NSThread: 0x6000017342c0>{number = 8, name = (null)}

@uli The same applies here. Different threads are created for Default and IO, but these are reused for the respective dispatcher. On android it behaves like you said. There are no context switches. And my tests are running inside runBlocking.
iOS:

withContext wrapped in Default: <NSThread: 0x600001703140>{number = 6, name = (null)}
withContext wrapped Default 1: <NSThread: 0x600001703140>{number = 6, name = (null)}
withContext wrapped Default 2: <NSThread: 0x600001703140>{number = 6, name = (null)}
withContext wrapped IO 1: <NSThread: 0x60000176d1c0>{number = 8, name = (null)}
withContext wrapped IO 2: <NSThread: 0x60000176d1c0>{number = 8, name = (null)}
withContext wrapped IO 3: <NSThread: 0x60000176d1c0>{number = 8, name = (null)}
--------
withContext nested Default 1: <NSThread: 0x600001703140>{number = 6, name = (null)}
withContext nested Default 2: <NSThread: 0x600001703140>{number = 6, name = (null)}
withContext nested IO 1: <NSThread: 0x60000176d1c0>{number = 8, name = (null)}
withContext nested IO 2: <NSThread: 0x60000176d1c0>{number = 8, name = (null)}
withContext nested IO 3: <NSThread: 0x60000176d1c0>{number = 8, name = (null)}

Android:

withContext wrapped in Default: DefaultDispatcher-worker-2
withContext wrapped Default 1: DefaultDispatcher-worker-2
withContext wrapped Default 2: DefaultDispatcher-worker-2
withContext wrapped IO 1: DefaultDispatcher-worker-2
withContext wrapped IO 2: DefaultDispatcher-worker-2
withContext wrapped IO 3: DefaultDispatcher-worker-2
--------
withContext nested Default 1: DefaultDispatcher-worker-5
withContext nested Default 2: DefaultDispatcher-worker-5
withContext nested IO 1: DefaultDispatcher-worker-5
withContext nested IO 2: DefaultDispatcher-worker-5
withContext nested IO 3: DefaultDispatcher-worker-5

[uli]

So it seems, iOS is just using 2 thread pools, without any optimization

[Niklas]

Yep, thanks for the help :)