Also it is a way to bind the coroutine(s) to an app specific lifecycle.īehind the scope there is the concept of structured concurrency that helps us, the developers, to avoid leaking coroutines which can waste the resources (disk, memory, cpu, network). The scope is used in order to track the lifecycle of the coroutine. That’s why it’s called internal concurrency.Ī coroutine should run in a scope. In a single thread, only a single coroutine is processed at a time. The number of coroutines scheduled for execution can be more than a million. We can compare a coroutine with a usual task that can be done by an employee. A coroutine = piece of code that can be suspended and resumed. It is similar to threading, except coroutines are even more light-weight. In Kotlin to achieve this we use the coroutines library ( routines ).

Supporting processing multiple tasks is called internal concurrency.

Coroutines are actually lightweight threads. When that block is over, you have the guarantee that no ongoing work is left dangling in the background, and you also save time and resources by cancelling it if any other concurrent subtask (or the main task) fails.Coroutines are officially part of the Kotlin standard library starting with version 1.3 and they are very helpful in creating concurrent non-blocking code. You don't show where you call await() on your launched coroutine, but as a rule both the async and await statements should occur within the same coroutineScope block. Async(Dispatchers.IO) will be basically a no-op.Īs Tenfour04 brings up, launching off background work and awaiting on its result should be encompassed by a single unit of work, which should immediately fail as soon as any part of it fails.

With context kotlin