Funny, I thought about a road lanes analogy (which the picture makes me think of), actually wanted to use at my first public talk about coroutines at Mobilization (but didn't because I didn't have time to make a supporting visual)

It's a great post. What I miss here is a discussion about throttling and backpressure which io threads brings to my mind.

As for me -- it's subtle difference between suspend and non-blocking in general, 'cause suspend wraps blocking code, making it non-blocking (IO), or less-blocking (CPU)

Minor point: NetworkOnMainThreadException link is not working (there’s a rogue “%5C” at the end)

@Mark Thanks. Corrected and clarified.

Great article Roman!

Also bearing in mind that a suspend function shouldn’t leave anything behind, does that mean it would be common for such a function to have both a

coroutineScope{}

and

withContext(dispatcher) {}

surrounding the main body?

@Mark

withContext

already creates a scope, no need for an additional one.

So

withContext()

will not return until all child jobs complete?

@Mark

withContext

gives you a scope as a receiver for le block you pass to it, but no, it only folds the context you pass to it with the current context, so it doesn't wait for any child coroutine you start (the parent scope will). That said, I have never launched a coroutine from a

withContext

block.

It actually does wait

@elizarov Try this snippet on play.kotl.in:

suspend fun main() = coroutineScope {
    withContext(Dispatchers.Default) {
        println(1)
        launch {
            delay(1000)
            println(2)
        }
        println(3)
    }
    println(4)
}

Hm… Something is not right on play.kotl.in…

For reference, the snippet above prints this:

1
3
4
2

which shows that

withContext

call resumes before its child coroutine is completed.

It looks like some older version of the library — we’ve fixed that before release. With 1.0.0 on my machine it prints 1, 2, 3, 4

It'd be nice to be able to see which "third party" library versions are used on play.kotl.in and try.kotl.in (which has the same behavior)

We shall embed library version somewhere, so that you can query it….

Then there's a bug if it prints

1, 2, 3, 4

, it should print

1, 3, 2, 4

😉 I assume you mistyped it

Mistyped.

I’m curious when one would use

coroutineScope{}

(instead of

withContext()

) within suspend function? I guess when you don’t want to specify the

Dispatcher

, but that seems odd

It is not odd at all if you follow convention to encapsulate threading decisions. If your suspending function only calls other suspending functions, then it should not be using

withContext

but

coroutineScope

maybe some lint checks for that would be useful?

@Mark I don't see how it could be done.

withContext

takes a parameter,

coroutineScope

does not. I don't see how a lint check would/should assume that you should not call

withContext

but use

coroutineScope

instead.

Yes, I’m assuming this “If your suspending function only calls other suspending functions” can be implemented as a lint check. Maybe it can’t (and I really don’t know much at all about lint), though I’d be surprised from what I’ve seen other lint checks are capable of.

I currently use this syntax: https://github.com/Kotlin/kotlinx.coroutines/issues/428#issuecomment-434381951 If this

operator fun invoke

thing never makes it into the library, then I think your

coroutineScope(context: CoroutineContext = EmptyCoroutineContext) { … }

proposal is a good idea. Maybe you could create on issue for that on GitHub, @Mark?

I really don’t know if the proposal makes sense (since I’m very new to coroutines) so I’d be happier if someone with more experience wants to pick it up instead.

Difference in vocabulary reflects difference in intent. You use withContext to wrap blocking code. In the other hand, coroutineScope is used when you decompose your code into multiple concurrent operations via launch or async.

Wouldn’t you also use

withContext

for non-blocking code (e.g.

withContext(Dispatchers.Main)

) when touching the UI? And couldn’t you also “decompose your code into multiple concurrent operations via launch or async” when using

withContext()

as in the earlier

1, 3, 2, 4

example?

It works for blocking code but also code that needs to run on a specific thread. It's called

withContext

, not

runBlocking

, so the use cases go beyond just running blocking code off the calling thread. Usually, when you use

Dispatcher.Main

, you use it as default dispatcher for the UI component root scope.

@elizarov I'm having a conversation about withContext(IO) from suspend commands in a library. https://github.com/square/okio/pull/531. I personally think that a library suspending function should not enforce a dispatcher as it could generate unneeded context switch. Is there already a consensus about how libraries should well behave? And proper way to manage that?

The default dispatcher would not context switch unless needed (unless you are running in the main thread). So, IMO, libraries should encapsulate their blocking code inside

withContext

to make life easier for consumers.

My concern is more about custom dispatchers for a context. Until https://github.com/Kotlin/kotlinx.coroutines/issues/261 is reality. If I have some kind of ressource control having the library suspend function switch to IO will generate switching + break the limits enforcing and not easy to debug issues in that case.

Yes. Custom dispatchers are still an open issue. We’ll design an API for them, though.

So for the moment libraries should already do withContext(IO) and it's up to consumer in custom dispatchers to async.await or runblocking until custom dispatchers can share threads with them.

Neither async.await nor runblocking should be needed, or I don’t get your use-case

I want to ensure that for a specific server I never have more than 3 active connections, so I have custom theadpool.asdispatcher and run the commands via launch { suspendfunction() }. The function is ran in my context so I know there will never be more than 3 blocking connection. If the suspend function is from the library and use withContext(IO) then the limits are not enforced and at any moment there can be 64 active connections no? Or there's something I missed in the suspend / non blocking and parallelism in the docs.

You approach would only work in a tightly coupled system with blocking IO and breaks when you switch to non blocking, for example. Better use coroutines worker pool. See my latest talk

Really nice talk, but I'm still lost at how to build real implementation as for the moment you do not provide the abstraction for that and channels are still experimental 😞 The need is global to all access to 1 resources, and there's about 50 different needs, not just a single downloader to limit. The concurrency limit needs to apply to any of those 50 functions at any time. I do not even see how it goes with https://github.com/Kotlin/kotlinx.coroutines/issues/261. In that issue you give the example of limiting the DB access to X, but I assume it's because you assume all DB access are blocking? I suppose for this particular need, I should keep on blocking calls to ensure the limits then and see how things evolve in the future as I'm sure proper solutions will be provider later.