kotlinlang #coroutines

So, if your framework installs some default context (with authorization, dispatching, logging and all the other aspects), then all the subcoroutines (children coroutines? I don't really know how to name them) that you start with

kotlinx.coroutines

builders to do some work in parallel will automatically inherit the context.

elizarov

01/17/2017, 9:36 AM

But user code can amend the context. The simplest example is naming your coroutines with

runSuspending(CoroutineName("MyName")) { ... }

voddan

01/17/2017, 10:25 AM

@elizarov did I understand it right that

runSuspending

will mainly be hidden by a particular framework with all the characteristics of the framework hidden in the context, but the end user will be able to freely mix frameworks by mixing contexts?

elizarov

01/17/2017, 10:26 AM

That is the idea.

elizarov

01/17/2017, 10:26 AM

The other idea is that the actual implementation of

runSuspending

kotlinx.coroutines

will understand the concept of the current context, so you can use

runSuspending

to "fire-and-forget"new coroutine in the current context.

elizarov

01/17/2017, 10:27 AM

For example, here is how you might implement yourself a

flatMap

operation for

rx.Observable

(if it were not already there):

elizarov

01/17/2017, 10:30 AM

Copy code

fun <T> Observable<Observable<T>>.flatMap() = observable { // use a coroutine builder to build observable by yielding values
    for (obs in this) { // use suspending iteration extension on observable
        runSuspending { // run a fresh coroutine for each obs: Observable<T> 
            for (element in obs) { // now iterate on the element of obs in a separate coroutine
                yield(element) // yield to result
            }
        }
    }
}

elizarov

01/17/2017, 10:31 AM

Basically, you'd use

runSuspending

if you just need to do stuff in parallel with whatever else you were doing in the same context.

elizarov

01/17/2017, 10:31 AM

This way,

runSuspending

will be an end-user primitive

voddan

01/17/2017, 10:32 AM

But in this example you don't pass contexts by hands!

elizarov

01/17/2017, 10:32 AM

Exactly.

voddan

01/17/2017, 10:32 AM

Are there legitimate situations where you would?

elizarov

01/17/2017, 10:32 AM

That magic code will be in

kotlinx.coroutines

elizarov

01/17/2017, 10:32 AM

I would only amend the context, by overriding some items or putting new ones.

elizarov

01/17/2017, 10:34 AM

The implementation of

runSuspending

will be somewhat like:

Copy code

fun runSuspending(context: CoroutineContext = EmptyContext, block: suspend () -> Unit) {
    val actualContext = currentContext + context
    // now use actualContext to start coroutine
}

teedee

01/17/2017, 10:34 AM

Wouldn't it be more explicit if all the builders are provided by

kotlinx.coroutines

and their behaviour would depend on the contexts that are passed to it?

elizarov

01/17/2017, 10:35 AM

Frankly, I don't know.

elizarov

01/17/2017, 10:35 AM

Here are the basic facts:

elizarov

01/17/2017, 10:37 AM

We want user to be able to specify his own context. Why? Because I don't want to cut-and-paste every builder for every use case. I want to be able to do

runSuspending(Swing) { ... }

runSuspending(MyComputePool) { ... }

with ease.

elizarov

01/17/2017, 10:38 AM

Now,

runSuspending

is a simple builder you might say, but there are bunch more complicated ones, and I don't want to cut-and-paste all of them. Especially, if you take into an account a variety of futures/promises implementation. There will be a builder for each one of them! I want to compose any builder with any context.

elizarov

01/17/2017, 10:39 AM

Now, do we really need the concept of

currentContext

? E.g. what shall be the default behavior of

runSuspending

be? Shall it, by default, use an empty context or inherit the context of the parent coroutine?

elizarov

01/17/2017, 10:40 AM

It is worth noting, that context go way beyond execution environment like

Swing

. They are essential for debugging.

elizarov

01/17/2017, 10:40 AM

Coroutines are extremely lightweight

elizarov

01/17/2017, 10:42 AM

Out-of-the box they don't have name, don't even have any kind of idenity. When coroutine resumes on some thread you don't even have its original stacktrace anymore, so you don't have any clue where it came from. Bare coroutines are very efficient, but extremely hard to debug.

elizarov

01/17/2017, 10:43 AM

So,

kotlinx.coroutines

is going to provide some facilities to name coroutines, cancel coroutines, give then identity!

👀 1

elizarov

01/17/2017, 10:44 AM

Now cancellation is very important. The running coroutine is easy to loose. When it is suspended you don't see it anywhere. There is no threaddumps, nothing. It just sits in memory waiting for something.

elizarov

01/17/2017, 10:45 AM

Assume, you have some server-side (web) framework. Each incoming request is a coroutine. Usually it does something serailly, but sometimes you need to forkoff some parallel stuff. You use

runSuspending

. It is imperative that is inherits the contest of the coroutine that processes the request, so that it is cancelled as soon as the request is completed for any reason.

elizarov

01/17/2017, 10:48 AM

What do you do if you want to start a coroutine that outlives its parent coroutine? You use the fact, that all coroutine builder accept an optional context parameters, so you do

runSuspending(Lifetime()) { ... }

, so you construct a fresh lifetime for that coroutine explicitly, that is not bound to the lifetime of the current coroutine.