Hi, I wanted to see how `scheduleResumeAfterDelay`...

# coroutines

[Rohan Maity]

Hi, I wanted to see how scheduleResumeAfterDelay works, upon looking into the code, this method is implemented by several CoroutineContexts like HandlerContext , DarwinContext
But I cannot find these files in kotlin coroutines github repo
Can someone help me here, what I am doing wrong here?

[Sam]

Delays and scheduling are implemented by the dispatcher, which is part of the coroutine context.

[Sam]

The fact that HandlerContext mentions the word "context" in its name is slightly misleading. That class is actually part of the implementation of the HanderDispatcher, which you can find here. Meanwhile the Darwin dispatcher you mentioned is probably this one, although it doesn't include a class named DarwinContext.

[Sam]

This search will be helpful for finding other implementations of the function you're interested in.

[Rohan Maity]

Ok, I have one more question now, why dispatcher has to extend/implement CorutineContext?

Like how dispatcher and coroutinecontext are related?

I know dispatchers are the one which tells where to run the coroutine, (which is a part of context I guess) but is there anything else which this coroutine context signifies?

[Sam]

Normally the coroutine context is like a set that contains a few different "context elements". The dispatcher is a context element, and so is the Job, which tracks whether the coroutine is started, completed, cancelled, etc. The context can also contain a handler for uncaught exceptions; a coroutine name for use when debugging; and some "thread local" elements for integrating with thread-based Java code.
The thing that can make it confusing is that each individual context element can be used as a singleton context in its own right.

val context2 = Dispatchers.Default + Job() // context containing two elements
val context1 = Dispatchers.Default // context containing only one element

[Rohan Maity]

Understood, and thanks for touching upon the confusion part. I am thinking whether there use case of "each individual context element can be used as a singleton context in its own right" ?
I mean I don't think this kinda confusion would be unintentional