Suppose I have ```suspend fun myFun() { repeat...

# coroutines

[Mark]

Suppose I have

suspend fun myFun() {
    repeat(100) {
        someSuspendingFunSpecifyingIODispatcher()
        someQuickNonSuspendingFun()
    }
}

At the top-level of myFun() is it better to have withContext(Dispatchers.IO), coroutineScope {} or leave it as it is?

[gildor]

Leave it as it is

[gildor]

I see no reason to wrap to IO or creating new scope if you just use regular functions

[Mark]

wouldn’t there be more potential context switching if the caller calls using, say, Main dispatcher?

[gildor]

Why so?

[Mark]

I’m guessing there would be some kind of switching from Main to IO each time someSuspendingFunSpecifyingIODispatcher() is called

[gildor]

Sure

[Mark]

but with withContext(Dispatcher.IO) there wouldn’t be

[gildor]

Yes, but it will be on withContext, you just moved it a bit and create unnecessary scope and suspend point and make it less readable

[gildor]

Without any performance gain

[Mark]

Just to be clear, I don’t mean the withContext() inside the repeat(), I mean at the top level

[Mark]

suspend fun myFun() = withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
    repeat(100) {
        someSuspendingFunSpecifyingIODispatcher()
        someQuickNonSuspendingFun()
    }
}

[Mark]

Wouldn’t that run entirely on IO dispatcher? Surely more efficient?

[gildor]

I see what you mean

[gildor]

Problem that you leak implementation details

[gildor]

Of someSuspendingFunSpecifyingIO

[Mark]

For sure it’s a potential optimization. Knowledge that something will run in IO, means we have the option to choose a strategy knowing that.

[gildor]

If this function is blocking (require run on IO) and it's private it would even more performant to do not make it suspend and do not switch any context, just keep it blocking and switch context before repeat

[Mark]

Thing is, I have all these utility methods working on Files and InputStreams and I’m making them all suspend functions and wondering whether I should be putting withContext(Dispatchers.IO) at the top of each one. Or just at the lowest level.

[Mark]

Oh I see

[gildor]

If it public general usage function and you want easily and safer use it from suspend function, that this function should switch context explicitly inside of the body

[gildor]

If you need performance for some higher level functions, than just use blocking functions to avoid suspend point creation, allocations and context switches

[Mark]

Ok, so in general keep a bunch of private blocking functions and public suspend functions that choose the correct dispatcher

[gildor]

Yes, this is how we try to organize such APIs

[gildor]

But again, if you want to make it a bit more performant

[gildor]

But careful with cancellation, check for isActive or call yield if you don't have other suspend calls between blocking calls to make it cancellation friendly

[Mark]

Do you use some kind of naming standard to distinguish between public suspend and private blocking functions? I can imagine there would be lots of cases where the former simply calls the latter (plus a withContext)

[pakoito]

But careful with cancellation, check for isActive or call yield if you don't have other suspend calls between blocking calls to make it cancellation friendly

why do you need to check for this, shouldn't the next suspension at someSuspendingFunSpecifyingIODispatcher just not be triggered?

[Mark]

I think he’s talking about the general case

[gildor]

I'm talking about case when you some suspend function that calls many blocking APIs. If you call suspend functions nothing worry about

[gildor]

I usually call function that blocks with Blocking suffix to make it explicit