👋🏻 Hey everyone, I'm looking to create a

CoroutineScope

which I want to run in the background while it's waiting for updates to be sent via a Channel, but once the update is sent, I want the result to be executed on the main thread. In that case, would I want to use

Dispatchers.Main.immediate

, something like this

CoroutineScope(Dispatchers.Main.immediate + Job())

? I think I'm getting a little hung up as I'm not sure when I would have a Scope that doesn't use that dispatcher (since I can launch a suspending function with the scope, but telling it to switch to a different dispatcher, say

IO

).

If you’re just calling

receive()

on a channel and waiting for a value to come in, you don’t need to use a special dispatcher for that. You can just receive from the channel on the main dispatcher.

if you use

immediate

dispatcher it might dispatch immediately if the message is also posted from the main thread, but that can be dangerous. if the messages are only sent from non-main threads, then there's no reason to use

immediate

@Zach Klippenstein (he/him) [MOD] I think I may see what you're talking about, instead of having a custom scope it'd just be using

MainScope()

?

Sure, that's one way to do it. The IO dispatcher is for blocking calls that block the current thread by not doing any work, but just sitting there waiting for the OS to return a value.

Channel.receive()

is a suspending call, which means it doesn't block the thread, and can thus be invoked from the main thread.

Yeah but

receive

can only be invoked from another suspending function so I need to use

CoroutineScope.launch

somewhere. So from the consumer side it's essentially this:

abstract class FooStatusConsumer(
    coroutineScope: CoroutineScope,
    channel: Channel<FooStatus> = Channel()
) {
    init {
        coroutineScope.launch(<http://Dispatchers.IO|Dispatchers.IO>) {
            for (fooStatus in channel) {
                withContext(Dispatchers.Main) {
                    consume(fooStatus)
                }
            }
        }
    }

    abstract fun consume(fooStatus: FooStatus)
}

why not

Dispatchers.Main

at the top, drop

withContext

?

That's what I'm trying to figure out. My understanding is I'd want to switch to the IO dispatcher before I start IO work which I would think waiting for channel updates would warrant that. Before sending updates though I would want to ensure I'm doing so from Main which is why I have a second context

that's what zachklipp was getting at though -- suspend functions don't block threads

I getcha, for whatever reason your message made a bit more sense. So if it's just calling a suspend function, as long as you

launch

from a scope then you are good to go. I'm guessing if I wanted to kick off the suspend function from the IO or Default dispatcher that's when I'd use a scope which started with that... But in the majority of practical situations

MainScope()

is probably a decent place to start

yes, usually I remain in one dispatcher for the most part, and only if I need to do something blocking do I

withContext(<http://Dispatchers.IO|Dispatchers.IO>)

-- whether that be the Main or Default dispatcher depends on which part of the code I'm in

In fact, using the IO dispatcher just to receive from a channel could actually be slower, because if something is already in the channel then it has to jump to the IO pool’s queue, and then back into the main queue, instead of just pulling the next available item out immediately and starting to process it.

Awesome, thanks guys this makes so much more sense now 🙇🏻