Noob level question: What is the difference between suspend functions and normal functions when calling from a coroutine? I mean, even if you call normal functions, they still run asynchronously, right?

I would say the opposite. When you're inside a coroutine, calling

suspend

functions and regular functions feels the same - they are run sequentially, in a manner that appears synchronous as far as the code is concerned (the next line of code will be executed after the function returns, and can access the return value of the called function). If you're calling a suspend function, the current thread may be freed to go execute some other work (we call this a suspension point because the coroutine may be suspended when making this call), so it's behaving asynchronously behind the scenes despite the synchronous aspect of the code. However, if you call a regular function, the thread is actually blocked until the function returns, so there is a difference.

Calling a

suspend

function creates a suspension point. Calling a regular function will always execute in the same callstack

Yes, I should rephrase. Regardless of the

suspend

keyword, the code inside a coroutine is run sequentially. However, because we're inside a coroutine, the entire block of code can be run on a different thread (using Dispatchers) For common use cases, like Room, shouldn't this be enough? How does using

suspend

make a difference? An example would be very much preferable. Thanks

when calling a suspend function, your current function will be suspended. for example,

withContext(IO) { database() }

will free up the current thread to run other coroutines while IO is proceeding, while

database()

will block the current thread if it is not a suspend function, even if it's using another thread to perform its work

So if we are in the main thread and execute:

CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO>).launch { database() }

where database is NOT a suspend function It will still block the main thread?

Not sure what you mean by

CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO>) { database() }

, as this doesn't compile. If you meant

CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO>).launch { database() }

then you're creating another coroutine here, so things are much different.

launch

is not a suspend function itself, and it's actually how you make asynchronous calls, so the code after the call to

launch

will run concurrently with

database()

. The main thread would not be blocked, but the current coroutine wouldn't even be suspended anyway. If you meant

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

, like @ephemient suggested above, it's a different story.

withContext

itself is suspending, so the current coroutine (which calls

withContext

) suspends when making the call (that's a suspension point), and the code after

withContext

will only run once the

database()

call is done. However, that doesn't mean the main thread will be blocked. Instead, the main thread just stops executing this specific coroutine, but it can run other coroutines while the current coroutine is waiting for the result of

database()

. Once

database()

completes (on whatever IO thread it was using), the main thread can resume executing the initial coroutine.

Thank you for going in such detail. Then, in a nutshell, suspend is just sugar syntax for callbacks? And suspension points have nothing to do with multi-threaded programming. Rather they only change the order in which the code is executed, albeit on the same thread. More importantly, even if we call a suspend function on the main thread, it only blocks that specific coroutine but leaves the thread open to run other coroutines concurrently. Is that correct?

Expanding on the example above, things may behave slightly differently depending on the dispatchers used to run this code. Let's assume

doStuff()

is called on the main thread, and

someScope

has a dispatcher that runs stuff on the

Dispatchers.Main.immediate

(which is what happens if you use Android's built-in scopes like

lifecycleScope

or

viewModelScope

). If

someFunction

is not suspend, it has to block the thread running the

launch

block until it completes, which means blocking the main thread here. Because of

Dispatchers.Main.immediate

the launch body will not only run on the main thread but also run first (before

doStuffConcurrently

). So even though

doStuffConcurrently()

theoretically runs concurrently with the

launch

body, it will not be able to run until

someFunction

is done in this specific case due to thread starvation (because

someFunction

block the main thread). That's why if

someFunction()

does blocking I/O operations, it's better to override the dispatcher to make sure it runs on another thread or pool of threads. This is what

<http://DIspatchers.IO|DIspatchers.IO>

is for. Now, if

someFunction

is

suspend

, the call to it is a suspension point in itself, but also

someFunction

itself may contain suspension points inside (if it calls other suspend functions). Having multiple suspension points allows pieces of code from concurrent coroutines to interlace even when run on the same thread.

@Advitiay Anand Yup, suspend is like a callback that is called with a result (a value or Unit) or with an exception. That callback is a Continuation<T> The compiler allows the Continuation to appear on the left side of the expression (instead of on the right side as an input parameter), as a return value, allowing for a sequential/imperative programming style. suspend fun someFun(...): T is rewritten as fun someFun(..., Continuation<T>)

This is still the best source to understand this IMO if you're interested:

That video is great, quite detailed! 😀

☝️ yep that doc too, although it goes into even more details, so brace yourself!

there are callbacks but it's not the type of continuation-passing you would write by hand. each suspend function is turned into a state machine which will proceed to the next suspension point each time it is resumed, as well as being able to both call functions inline or dispatch them

Yup, seeing it as callbacks is a very simplified view. 😀 But that's the 10,000 feet view of 'suspend' for me. That a 'suspend' becomes Continuation is just one aspect. The guarantee that suspend funs can be called sequentially/imperatively in a safe way needs much more, like the state machine (with 'goto' statements) you describe.

yep, the "Continuation" aspect really shouldn't matter for how you use coroutines. suspension points as locations in the source code where execution can switch from one callstack to another, but otherwise everything that looks like sequential code will execute sequentially