I'm trying to understand the basics of Coroutines, the basics, but I don't understand at all what "suspending" means in this coroutines topic. Let's suppose I have my suspending function

fun suspend foobar() { dostuff }

, if I call that function from a coroutine, I understand from the documentation that calling foobar will suspend the coroutine, so does that mean foobar won't be executed? Why would I want to do that? It does not make any sense in my head. I know I must be understanding something really wrong

If a function is marked as

suspend

, that doesn’t mean it will suspend the coroutine, it just means that it might.

When will it suspend the coroutine exactly?

I find it helpful to always map coroutine concepts back to callbacks in my head, because that’s what they are under the hood. In your example, a callback rewrite might look like:

fun foobar(continue: () -> Unit) {
  dostuff
  continue()
}

Aren't all "normal" function "suspend" functions? Because, when they are called, they "block"/"suspend" the routine which called it until they return their result

The simplest explanation is that a function marked

suspend

is chopped up into smaller pieces, and those pieces do not need to be processed immediately one after the other. Instead, each block can be suspended to be resumed as some later point in the future, potentially on a different thread. The compiler does the work of chopping a

suspend

function into these chunks, and the runtime library does the work of suspending/resuming these chunks.

that’s a great question! You’re right, the caller temporarily stops execution while the child runs. The difference is that, with normal functions, the thread that the caller is on stays occupied running the child, and the thread can’t do anything else until the child returns. With suspend functions, the rest of the execution of the function can get wrapped up into a callback and later invoked somewhere/sometime else, and the thread can be freed up.

This article goes pretty deep into this topic, but is very helpful for understanding the difference. At the surface, the concept of blocking vs suspending seems very similar, but it’s in the way the code is actually executed at runtime that makes them very different, and where the power and flexibility of coroutines comes from https://medium.com/@elizarov/blocking-threads-suspending-coroutines-d33e11bf4761

Thank you! I hope I have more luck this time, I have already watched two hours of video of conferences from Roman Elizarov 😂

The basic idea is that it’s chopped at any point where another

suspend

function is called, which is called a “suspension point”. This is why

suspend

functions can only be called within other

suspend

functions/lambdas. By being inside a

suspend

function, the compiler knows to start chopping things up when calling other

suspend

functions

That sounds like it's going to "chop" a lot more than necessary, specially when you have a stack trace of lots of suspend function calls that are simply "suspend" because there's some needed really async/suspend call at the bottom of the stack

Yes, that’s all true. There are a lot of chunks being made, the bytecode generated is quite a bit larger, and the execution is sequential by nature. By unlike blocking a thread, a suspending coroutine consumes virtually no system resources. Blocking a thread means that thread cannot process anything else. Suspending a coroutine means that the thread executing that chunk is free to handle other chunks that are ready to continue working. While a powerful compuer can only have a few thousand threads active, you can easily have millions of coroutines active at one time, even on a single-threaded program (such as in Kotlin/JS)

That makes me wonder why it wasn't implemented in any other "popular" language, what's the disadvantage?

How does the compiler know where to make the “chunks”?

I think it’s probably more accurate to say this happens at the special

suspendCoroutine

function. This is the function that actually gives you a callback that represents the rest of the function.

It sounds really complex to me, so If you have 2 threads and 500 coroutines waiting to resume execution, you will need a policy to decide what coroutine is resumed, that decision could fail badly, it's like doing the work of the OS but made by the Kotlin compiler 😂

you will need a policy to decide what coroutine is resumed

Again, yes.

Dispatchers

are that policy. But even Java’s exceptions are a layer of error-handling built above the OS level. Most languages and frameworks need to implement their own form of error-handling specific to that domain, and this, too, is part of coroutines. Under-the-hood, it’s basically just throwing and catching exceptions with a small bit of logic to track which chunks threw the exception and which ones caught it (basically, the

Job

interface).

how can this work so efficiently

If you’re constantly jumping between threads, it’s just as expensive as a normal thread context-switch. But most code don’t jump between threads that often, just a couple of times, and when it’s “jumping” between chunks without that thread switch it’s little more than a regular function call

As Roman explains in the article you gave me, there is two natures of blocking, an extremely cpu intensive task, and waiting for a looong I/O operation, so coroutines only "solve" the problem for waiting at a long I/O operation (where the cpu is idle, only waiting), isn't it? It might sound a kinda dumb question but I'd like to be sure

no, coroutines are useful for other purposes as well

While CPU-bound tasks are more difficult to manage, they do still fit into the overall architecture. You just need to know that code can still block a thread in coroutines, and that they don’t magically turn blocking code into non-blocking code. If a CPU core is stuck running or forcibly waiting idle (

Thread.sleep()

), then coroutines can’t do too much. Ultimately, it’s just running normal code in smaller chunks interwoven in clever ways, but they can’t really do anything in the middle of a chunk. CPU-bound tasks are essentially just really large chunks, and as such the framework can’t fix that for you. But they can make it easier to move that giant chunk to the threads best suited for processing it (

Dispatchers. Default

), or providing you tools for breaking a large blocking code chunk into smaller chunks (

suspendCoroutine

Zach mentioned above)

Thank you very much to all, I have to think but it's clearer than an hour ago

If it helps... the whole "suspend" thing has confused me since day 1 too. I just think of them as syntactic sugar for callbacks and call it a day.

Super interesting thread. Took me a while to understand not only

suspending

but also what

structured concurrency

fully meant in the context of coroutines

@Carrascado This might help: https://github.com/JetBrains/kotlin/compare/document-coroutines-codegen I tried to cover everything, but there are still ~2k lines to go (fix grammar and style etc.). You can skip parts unrelated to your question, such as "Suspend Marker", "Layout" etc (it can help to understand how exactly the compiler does its job, but it might be too specific) and focus only on suspension, resumption and interception.

Thank you guys for your answers! At least I don't feel alone anymore 😂 Thank you! @Ilmir Usmanov [JB]! I'm gonna check it out

Here’s another article that actually inspects the (decompiled) bytecode generated by the compiler, which helped me understand more about how the compiler “chops up” the code and wires it all together with Continuations https://www.infoq.com/articles/kotlin-coroutines-bottom-up/

Thank you @Casey Brooks I'm gonna check it out too, I hope I understand them better that way!