The purpose of coroutines is to take care of the complications in working with asynchronous programming. You write code sequentially, like you usually do, and then leave to the coroutines the hard work. Coroutines are a low-level mechanism. The end objective is to build accessible mechanisms like async/await in C#
Coroutines are an experimental feature, introduced with Kotlin version 1.1. They have been created to manage operations with long execution time (e.g., Input/Output operations with a remote resource) without blocking a thread. They allows to suspend a computation without keeping occupied a thread. In practical terms, they behave as if they were light threads with little overhead, which means that you can have many of them.
In fact, traditional threads have a flaw: they are costly to maintain. Thus it is not practical to have more than a few available and they are mostly controlled by the system. A coroutine offers a lightweight alternative that is cheap in terms of resources and it is easier to control by the developer.
Suspension Points
You have limited control over a thread: you can create a new one or terminate it, but that is basically it. If you want to do more you have to deal with system libraries and all the low-level issues that comes with them. For instance, you have to check for deadlock problems.
Coroutines are a easier to use, but there are a few rules. The basic ideas is that coroutines are blocks of code that can be suspended, without blocking a thread. The difference is that blocking a thread means the thread cannot do anything else, while suspending it means that it can do other things while waiting the completion of the suspended block.
However you cannot suspend a coroutine at arbitrary positions. A coroutine can be suspended only at certain points, called suspension points. That is to say functions with the modifier
.
suspend fun answer() { println("Hello to you!") }
The behavior is controlled by the library: there might be a suspension in these points, but this is not a certainty. For example, the library can decide to proceed without suspension, if the result for the call in question is already available.
Functions with suspension points works normally except for one thing: they can only be called from coroutines or other functions with suspension points. They cannot be called by normal code. The calling function can be a (suspending) lambda.
Launching a Suspension Function
The simplest way to launch a suspension function is with the
function. It requires as an argument a thread pool. Usually you pass the default
.
import kotlin.coroutines.experimental.* // notice that it is under a package experimental suspend fun answer() { println("Hello to you!") } fun main(args: Array<String>) { launch(CommonPool) { answer() // it prints this second } println("Hello, dude!") // it prints this first Thread.sleep(2000L) // it simulates real work being done }
Notice how the coroutines are inside a package called experimental, because the API could change. This is also the suggested approach for your own library functions that implement coroutines. You should put them under an experimental package to warn them of the instability and to prepare for future changes.
This is the basic way, but in many cases you do not need to deal directly with the low-level API. Instead you can use wrappers available for the most common situations.
In fact, coroutines are actually a low-level feature, so the module itself
offers few high-level functionalities. That is to say, features made for direct use by developers. It contains mostly functions meant for creators of libraries based upon coroutines (e.g., to create a coroutine or to manage its life). Most of the functionalities that you would want to use are in the package
.
From Callbacks to Coroutines
Coroutines are useful to get rid of callbacks. Assume that you have a function that must perform some expensive computation:
. This function calls a callback that receives the result of the computation and performs what is needed (e.g., it saves the result in a database).
fun solveAllProblems(params: Params, callback: (Result) -> Unit)
You can easily eliminate the callback using the
function. This function works by relying on a Continuation type (
in the following example), that offers a.
Coroutines And Sequences
The function
in one of the high-level functionalities of the basic kotlin.coroutines package. It is used to create lazy sequences and relies on coroutines: each time it runs it return a new result. It is designed for when you can obtain partial results that you can use instantly, without having the complete data. For instance, you can use it to obtain a list of items from a database to display in a UI with infinite scrolling.
Essentially the power of the function rests on the
mechanism. Each time you asks for an element the function executes until it can give me that element.
In practice, the function executes until it find the
function, then it returns with the argument of that function. The next execution continues from the point it stopped previously. This happens until the end of the calls of the yield functions. So the yield functions are the suspension points.
Of course, the yield functions can actually continue indefinitely, if you need it. For instance, as in the following example, which calculates a series of powers of 2.
val powerOf2 = buildSequence { var a = 1 yield(a) // the first execution stops here while (true) { // the second to N executions continue here a = a + a yield(a) // the second to N executions stop here } } println(powerOf2.take(5).toList()) // it prints [1, 2, 4, 8, 16]
It is important to understand that the function itself has no memory. This means that once a run it is completed, the next execution will start from scratch.
println(powerOf2.take(5).toList()) // it prints [1, 2, 4, 8, 16] println(powerOf2.take(5).toList()) // it still prints [1, 2, 4, 8, 16]
If you want to keep getting new results, you have to use directly
and
methods on the sequence, as in the following example.
var memory = powerOf2.iterator() println("${memory.next()} ${memory.next()} ${memory.next()}") // it prints "1 2 4"
The Async and Await Mechanism
Let’s see some of the functionalities of the package
. These are are the heart of the coroutines: the primitive parts are there to implement these functionalities, but you typically do not want to use. The exception is if you are a library developer, so that you can implement similar high-level functionalities for your own library.
For instance, it provides
and
, that works similarly to the homonym in C#. Typically they are used together, in the case in which an async function returns a meaningful value. First you invoke a function with
, then you read the result with
.
There is not an official documentation of these features, but you can find info about it on the GitHub project.
fun asyncAFunction(): Deferred<Int> = async(CommonPool) { 10 }
You can see that:
- the name of the function starts with async. This is the suggested naming convention.
- it does not have the modifiersuspend
, thus it can be called everywhere
- it returnsDeferred<Int>
instead ofInt
directly.
An example of how it can be used.
fun main(args: Array<String>) { // runBlocking prevents the closing of the program until execution is completed runBlocking { // one is of type Deferred val one = asyncAFunction() // we use await to wait for the result println("The value is ${one.await()") } }
The first interesting fact is that
returns
. So we can say that it unpacks the deferred type and make it usable as usual. The second one is the function runBlocking, that prevents the premature end of the program. In this simple case it is just an alternative to the usage of the old sleep trick (i.e., blocking the ending of the program with Thread.Sleep) to wait for the result of the asynchronous call. However the function can also be useful in a few situations with asynchronous programming. For instance, it allows to call a suspend function from anywhere.
The function essentially behaves like the following.
// example without await and runBlocking fun main(args: Array<String>) { // one is of type Deferred; val one = asyncAFunction() // wait completion while(one.isActive) {} println("The value is ${one.getCompleted()}") }
In the previous example we basically simulated the await function:
- we did nothing while the asynchronous function was active
- we read the result once we were certain it was finished
Channels
Coroutines can also implement Go-like channels: a source that send content and a destination that receive it. Essentially channels are like non-blocking queues, that send and operate data asynchronously.
import kotlin.coroutines.experimental.* import kotlinx.coroutines.experimental.channels.* fun main(args: Array<String>) { runBlocking { val channel = Channel<Int>() launch(CommonPool) { var y = 1 for (x in 1..5) { y = y + y channel.send(y) } // we close the channel when finished channel.close() } // here we print the received data // you could also use channel.receive() to get the messages one by one for (y in channel) println(y) } }
This code also produces the sequence of powers of 2, but it does it asynchronously.
A more correct way to produce the same results is using
function. Basically it bring a little order and take care of making everything running smoothly.
fun produceAFewNumbers() = produce<Int>(CommonPool) { var y = 1 for (x in 1..5) { y = y + y send(y) } } fun main(args: Array<String>) { runBlocking { val numbers = produceAFewNumbers() numbers.consumeEach { println(it) } }
The end result is the same, but it is much cleaner.
Pipelines
A common pattern with channels is the pipeline. A pipeline is made up of two coroutines: one that send and one that receive a stream of data. This is the more natural way to deal with an infinite stream of data.
import kotlin.coroutines.experimental.* import kotlinx.coroutines.experimental.channels.* fun produceNumbers() = produce<Int>(CommonPool) { var x = 1 while (true) // we send an infinite stream of numbers send(x++) }
The first coroutine is
which sends an infinite stream of numbers, starting from 1. The function rely on the aptly named
, that accepts a thread pool and must send some data.
fun divisibleBy2(numbers: ReceiveChannel<Int>) = produce<Int>(CommonPool) { for (x in numbers) { if ( x % 2 == 0) // we filter out the number not divisible by 2 send(x) } }
The second coroutine receive the data from a channel, but also send it to another one, if they are divisible by 2. So a pipeline can actually be made up of more channels linked together in a cascade.
fun main(args: Array<String>) { runBlocking { val numbers = produceNumbers() val divisibles = divisibleBy2(numbers) // we print the first 5 numbers for (i in 1..5) println(divisibles.receive()) println("Finished!") // we have finished // let's cancel the coroutines for good measure divisibles.cancel() numbers.cancel() } }
The example is quite straightforward. In this last part we just put everything together to get the first five numbers that are produced by the pipeline. In this case we have sent 9 numbers from the first channel, but only 5 have come out of the complete pipeline.
Notice also that we did not close the channels, but directly cancelled the coroutines. That is because we are completely ending their usage instead of politely informing their users about the end of transmissions.
The Select Expression
Select is an expression that is able to wait for multiple suspending functions and to select the result from the first one that becomes available. An example of a scenario in which it can be useful is the backend of a queue. There are multiple producers sending messages and the backend processes them in the order they are arrived.
Let’s see a simple example: we have two kids, John and Mike, trading insults. We are going to see how John insult his friend, but Mike is equally (un)skilled.
fun john() = produce<String>(CommonPool) { while (true) { val insults = listOf("stupid", "idiot", "stinky") val random = Random() delay(random.nextInt(1000).toLong()) send(insults[random.nextInt(3)]) } }
All they do is sending a random insult whenever they are ready.
suspend fun selectInsult(john: ReceiveChannel<String>, mike: ReceiveChannel<String>) { select { // means that this select expression does not produce any result john.onReceive { value -> // this is the first select clause println("John says '$value'") } mike.onReceive { value -> // this is the second select clause println("Mike says '$value'") } } }
Their insults are processed by the
function, that accepts the two channels as parameters and prints the insult whenever it receive one. Our select expression does not produce any result, but the expression could return one if needed.
The power of the select expression is in its clauses. In this example each clause is based upon
, but it could also use
. The second one is used to get a message when the channel is closed, but since we never close the channel we do not need it.
fun main(args: Array<String>) { runBlocking { val john = john() val mike = mike() repeat(6) { selectInsult(john, mike) } }
Putting all the pieces together is child play. We could print an infinite list of insults, but we are satisfied with 6.
The select expression clauses can also depend upon
of a
type. For example, we can modify our select expression to accept the input of an adult.
fun adult(): Deferred<String> = async(CommonPool) { // the adult stops the exchange after a while delay(Random().nextInt(2000).toLong()) "Stop it!" } suspend fun selectInsult(john: ReceiveChannel<String>, mike: ReceiveChannel<String>, adult: Deferred<String>) { select { // [..] the rest is like before adult.onAwait { value -> println("Exasperated adult says '$value'") } } } fun main(args: Array<String>) { runBlocking { val john = john() val mike = mike() val adult = adult() repeat(6) { selectInsult(john, mike, adult) } }
Notice that you should be wary of mixing the two kinds of clauses. That is because the result of
is always there. So in our example, after it fires the first time the adult takes over and keep shouting
whenever the function
is called. Of course in real usage you would probably make the select expression returns a result to check for the firing of the
clause and end the cycle when it fired the first time.
Summary
With this article we have seen what are coroutines and what they bring to Kotlin. We have also shown how to use the main functionalities provided around them and exploit their potential to make your asynchronous easier to write. Writing asynchronous software is hard, this library solves for you the most common problems. However we have just scratched the surface of what you can do with coroutines.
For example, we have not talked about all the low-level features for creators of libraries. That is because we choose to concentrate on the knowledge that will be useful to most people. However if you want to know more you can read the ample documentation on kotlin.coroutines and kotlinx.coroutines. You will also find a reference for the module and a deep guide on how to apply coroutines on UI (both Android and Desktop).
The post Introduction to Coroutines: What Problems Do They Solve? appeared first on SuperKotlin.