Is it correct to say that there is a "suspension point" at the start of all `suspend` functions?

# coroutines

[Thomas]

Is it correct to say that there is a "suspension point" at the start of all suspend functions?

[jw]

suspend functions execute synchronously until the first suspension point

[jw]

in fact, they can even return values or throw exceptions synchronously

[Thomas]

I see, so when exactly are suspension points created?

[jw]

At the call site of a suspend function

[Thomas]

ah it seems like I have flipped my understanding around 😂

[Thomas]

Each suspension point corresponds to a single "continuation state" of the generated code, yes?

[Thomas]

And therefore suspension points belong to the parent suspend function (where other suspend functions are called in), but not the start of a suspend function? 🤔

[ephemient]

https://github.com/JetBrains/kotlin/blob/master/compiler/backend/src/org/jetbrains/kotlin/codegen/coroutines/coroutines-codegen.md explains what the state machine looks like

[Liberty Tom]

So is it correct to say that a suspend function created a coroutine?

[Thomas]

I think not, a suspend function must be running inside a coroutine; a coroutine have to be created through a "coroutine builder"

[Pablichjenkov]

I believe if the Kotlin compiler does not see an indication of using a specific dispatcher. It will treat the suspend function as undispatched hence no suspension point, just direct execution. However, if some other parent suspend function specified a Dispatcher, the children suspend functions will execute in it.

[Liberty Tom]

So how to understand that suspendCancellableCoroutine ? From the method name, It seems like it would suspend a cancellable coroutine. But the block parameter is not in a CoroutineScope. So where is the coroutine that ``suspendCancellableCoroutine`` suspended?

[Pablichjenkov]

The fact that it is a suspend function enforces to call it from a coroutine created somewhere else with one of the coroutine builders. But perhaps they create another one too, I haven't seen the internal implementation.

[ephemient]

it hooks into coroutineContext[Job]

[ephemient]

(and if you call it from a non-kotlinx.coroutines coroutine, with no Job, it's basically a no-op)