Ok I'm still learning about coroutines, and I'm a bit confused with the coroutines builders zoo... Is this all correct? • launch: Creates a new coroutine. Code below

launch {}

continues being executed instantly (although because structured concurrency, coroutine will finally wait for its children to finish). • async: Creates a new coroutine. Code below

async {}

continues being executed instantly (although because structured concurrency, coroutine will finally wait for its children to finish). • runBlocking: Creates a new coroutine. Execution is blocked. Code below

runBlocking {}

won't execute until runBlocking has ended. • coroutineScope: Creates a new coroutine. Execution is suspended (it's the suspending version of runBlocking). Code below

coroutineScope {}

won't execute until coroutineScope has ended. Now, if this is correct, the only coroutine builder whose name makes sense is runBlocking 🤷‍♂️ The other ones seem to have absolutely random names. The 4 coroutine builders "launch" the coroutine, two of them are "asynchronous" in some sense (both launch and async), and 4 of 4 again have a "coroutine scope", what am I not understanding here? Why do they have these names?

I think

async

is the most surprising of these names, but I think it’s called that because it’s supposed to be one-half of the `async`/`await` keywords in other languages (javascript, python, c#). It’s probably named this way for discoverability and to hint at how it’s meant to be used for people familiar with async/await. But if you don’t have that context, the name does seem super random.

Absolutely, and the one which bugs me the most is coroutineScope, why is it not called runSuspending? Man the documentation should be reviewed by the devs... I'm having a hard time to understand anything. If I understand something now it's not because the docs but because I'm doing a lot of CSI stuff on the Internet

This is how I think about it, although I definitely see your point:

coroutineScope

doesn’t really create a new coroutine, really, anymore than

runBlocking

creates a new thread. It simply delineates a scope within which new coroutines can be created. Whereas

runBlocking

is usually used in a way where it will run a bunch of coroutines for some time and block the thread for potentially quite a long time (the “blocking” nature of the call is very important),

coroutineScope

is primarily meant to define a scope. The scoping is the more important thing, not the suspending.

So technically speaking coroutineScope is not a coroutine builder? And making a new scope... doesn't that destroy the idea of structured concurency? Because it won't be inheriting the parent scope anymore

The new scope does inherit from the parent scope, that’s the whole point.

And what does launch/async/runBlocking do with the scope, don't they inherit too? What's the difference then? 🤔

Everything (except

runBlocking

) inherits scope.

And launch is doing the same thing isn't it? It's creating a new Job and adding it to the scope

launch

and

async

create new jobs, yes. I don’t really think of them as “adding the job to the scope” though, since they aren’t mutating the current scope. They’re creating a new scopes which shares everything from the current scope, except the job is a child of the current job.

What's the difference then with using coroutineScope? Because if I have an explicit "scope builder" like coroutineScope, why do launch and async create new scopes too?

It’s important not to conflate “job” and “scope”. A job defines the lifetime of a coroutine. A scope contains a job, but also contains other context. So when you say a scope inherits from another scope, you’re really kind of saying two things: the child scope’s job is a child of the parent scope’s job, and the child scope might share some/all of the rest of the context from the parent (e.g. dispatcher, error handler, name, etc).

To me, that sounds like a heavy ton of implicit information from something called

coroutineScope

, specially when launch and async don't make you wait but they create new "coroutineScopes" too 😕

E.g. you might try to write something like

suspend fun doSomeThings() {
  launch { doFirstThing() }
  launch { doSecondThing() }
}

But that won’t work, because

launch

is defined as an extension function on

CoroutineScope

. And if it did work, e.g. you used the

GlobalScope

, then these coroutines would be leaked – if they never finished, then they would take up memory/resources forever. And there’s no way to cancel them. Instead you’d write:

suspend fun doSomeThings() {
  coroutineScope {
    launch { doFirstThing() }
    launch { doSecondThing() }
  }
}

And in your example, how does that

coroutineScope

know who is the parent scope? Is it the parent scope of the suspending function caller?

The job of the coroutine that calls

doSomeThings()

is the parent of the job inside

coroutineScope

, which is the parent of the jobs that

doFirstThing()

and

doSecondThing()

see.

Umm ok... and do you personally think this is well explained in the docs? Because I have spent more than a week trying to understand coroutines and I still don't get it well

Well the docs make sense to me now for the most part, but that doesn’t mean they would make sense to me if I was coming at this for the first time 😅

Soooo the only way to call launch and async from a suspend fun is using coroutineScope? Or is there some other strange edge use case for it?

Basically yes!

Thank you very much! I'm gonna check it out. By the way your example breaks structured concurrency, but doesn't

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

break it too? Why is it recommended practice?

However in that case, the scope’s job is not a child of the current job, so you’ve just broken structured concurrency.

Yes it does 🙂

I know you said it, I was affirming it, my english is sloppy sorry 😂

withContext

doesn’t break structured concurrency unless you pass in a job without a parent.

So the job hierarchy is what really "defines" the structured concurrency? Sorry I'm not really fluent in Kotlin (yet), do you mean that if Context has 5 properties, when you call

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

, it creates a new context with the new dispatcher but it defaults all the other stuff with whatever it was before?

So the job hierarchy is what really “defines” the structured concurrency?

YES! Exactly!

if Context has 5 properties, when you call withContext(Dispatchers.IO), it creates a new context with the new dispatcher but it defaults all the other stuff with whatever it was before?

Also yes!

I'm glad I'm understanding something at least 😂 Thank you for your time! I'm gonna watch your video

I nominate this thread to be permanently pinned on the channel. Brilliant.

old thread, but quick question.. this code(screenshotted to get the implicit type hints), the suspend function calls coroutineScope, who now can call a launch, who now is his own coroutine parented under the new scope. My simple question: how does the caller of

test()

which HAS to be a couroutine(since it is suspendable) get to become the parent of the

coroutineScope

defined in

test

? from the doc:

The provided scope inherits its [coroutineContext][CoroutineScope.coroutineContext] from the outer scope, but overrides
 * the context's [Job].

Is it just part of the

suspendCoroutineUninterceptedOrReturn

implementation that links the two?

old thread

Only two days 😛

I'm a bit curious about the question @taer made... but, inside every coroutine, what does really exist, a "current scope" or a "current context" at top level?

coroutineContext seems to be a local variable inside of suspend functions.

It’s not a local variable, it’s a top-level/global property. It’s basically shorthand for writing:

val coroutineContext = suspendCoroutine { continuation ->
  continuation.resume(continuation.context)
}

That is, the continuations that are passed around as the core currency of coroutines always contains the current context, which you can see by calling one of the

suspendCoroutine

functions to actually get access to a continuation.

coroutineContext

is just a convenient way to get it without the boilerplate.

But don't you mean that the core currency of coroutines always contains the current scope (not exactly the context)?

The only reason

CoroutineScope

is a thing at all is to serve as a place to hang extension methods off of. It’s a common pattern for functions that take lambdas-with-receivers to call the receiver type

SomethingScope

. But as far as the actual semantics are concerned for coroutines, “scope” and “context” are the same thing (a scope is just a different way of referring to a context).

That makes sense, so normally when people is talking about the context in coroutines, they might be referring to a CoroutineScope?

It’s more the other way around.

CoroutineContext

is the core data type that actually matters, it came before

CoroutineScope

, it actually holds the context, etc. And the two are effectively interchangeable –

CoroutineScope(CoroutineScope(CoroutineScope.coroutineContext).coroutineContext).coroutineContext

But... okay this question is kinda noob 😂 I'm seeing CoroutineScope as an Interface with Intellij IDEA, so, how can you call that

CoroutineScope

, isn't it a constructor?

Nope, it’s a factory function: https://github.com/Kotlin/kotlinx.coroutines/blob/1eeed509abbe8e542124841ce14884202463460b/kotlinx-coroutines-core/common/src/CoroutineScope.kt#L206

Oh okay thank you!

You're right that dispatchers are actually context instances themselves. CoroutineContext acts like a map, but it's implemented as a linked list. Every context "element" is both the thing that holds the value for its map entry, and a pointer to the rest of the map.

Job

is a context element. A dispatcher is a context element too. A context element is a context that only contains one element.

My head exploded, so it's like a composite pattern? I'm looking at the function, so there in the blue section it's getting the Job for the coroutine etc. and combining it with the dispatcher? (obviously in the case that you wanted to call it with Dispatchers.IO or something like that). Because I guess it needs a job in order to work (no pun intended)

Yep, pretty much.

Thank you very much, I'm understanding a lot more now

oldContext

is a map,

context

is a map,

oldContext + context

is like

+

-ing any maps – the keys in the left one are “overwritten” with the same keys in the right one.

Yeah, so it's like a "merge"