yeah, spock (and gradle) used to be my life until two years ago. unfortunately, silicon valley doesn’t want their engineers to work on OSS, even in their spare time. 😞 Hope to get my OSS life back eventually.

kotlinx-coroutines-rx

does not support cancellation yet.

ok, then there's one small problem. CriticalStuff() cant return value that i use for fallback. I have to use external var

@Deactivated User I’m a little bit concerned about naming. First, it looks confusingly similar to #ktor. Second, two-letter abbreviations of submodules doesn’t help me understand which module is doing what.

next time, name it Korra

Well, in my last job we migrated our whole flash codebase to haxe initially, then to kotlin 🙂

In general, that's an arbitrary FSM, which can be pretty much incomprehensible for IDEA's decompiler

I don't get the rxjava coroutines. Isn't the rxjava specifically designed for thread switching and combining data flows? What benefit do coroutines give?

Yep, scripting games would be nice fit for coroutines, e.g. quest scenario, non-path movements of monsters/NPC, etc. But in non-scriptable engines (like libgdx) it’s even more useful. E.g. consider a platform moving left and right. You will normally have to encode state machine by hand. With coroutines you can do it in a simple loop (pseudocode):

class Platform(left: Float, right: Float, vertical : Float, speed : Float) : Actor() {
…
fun suspend behaviour() {
    while (true) {
      for (x in left..right step speed) {
          moveTo(x, vertical) // frame-synced suspend function
      }
      for (x in right downTo left step speed) {
          moveTo(x, vertical)
      }
   }
}

Is it possible somehow with Kotlin coroutines to do a behaviour like: a request(r1) comes to server, this request is handled in a thread from thread pool, server does some work in that thread, after this server make a request to remote server, at this moment this thread should be returned to thread pool to handle another request(r2), after remote server returned a response, request(r1) should continue work from moment when was made a remote request

kotlinx.coroutines

version

0.7-beta

is published. It includes production-quality mostly lock-free implementation of Go-style channels that enable coroutines to safely share streams of arbitrary elements or messages without actually sharing any mutable state (e.g. share data by communicating). More details here: https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#channels

@elizarov nice work on the channels stuff. but its unusable:

send

and

recieve

are too conventional, its time we got some scala up in this and named them

!

and

<-

, or something similar. /sarcasm

The only significant difference I am aware of (beyond naming things), is that

async

in C#/JS/Dart uses implicit context (in C# that depends on the thread you are calling from, and in JS/Dart that's the event loop context), while in Kotlin we decided to make the context explicit.

@elizarov If you go forward with renaming

defer

to

async

, will you also rename

future

back to

async

?

If we combine it with renaming

Deferred

to

Asynced

, we can avoid the mismatch in names

Also, @elizarov, what about the general naming for coroutine builders? AFAIR, the initial idea was to create an API which would feel somewhat like language constructs. That would imply using short one-syllabic names for coroutine builders and scoping functions, but now we have monsters like

runBlocking {}

, etc. Can't we rename that into

blocking {}

?

Call it

blockBlock

, a verb and a noun. Problem solved.

CoroutineImpl seem to have been moved to another package between beta-18 and beta-38

@elizarov ohh, I forgot to add link to the project repo, I should sleep more 😅 https://github.com/gildor/kotlin-coroutines-android

Maybe

async

should return

Coroutine

class

@elizarov where will this be added ?

I wrote a first post on coroutines. If anybody wants to review it, you are welcome: https://medium.com/@gz_k/scale-out-pi-computation-with-kotlin-coroutines-4ee3ad294674 😉

How can I compose more sophisticated compsition like rxjavas switchMap?

You should not.

suspendCoroutine

is too low level. It takes large amount of code just to reliably pass a signal from one coroutine to the other. It is like writing your own blocking queue using volatile variables, atomics and LockSupport.

I don't argue against, I try to understand

Would this be the right way to transition from rxjava to coroutine?

before i dive too deep into it, are there any thoughts for

kotlinx-coroutines-jdk8

library to support helpers for

Channel

that adapt it to a

Stream

?

One thing: could you please add a performance comparison of different techniques for reference? Statements like

This is the fastest solution for this particular problem

are not very reassuring

Hi All, i've been doing some timings, based on variations of the "Shared mutable state and concurrency" examples form the coroutine guide and saw surprising results. First, here is my code:

val massive = 1_000_000
private suspend fun aMassiveRun(context: CoroutineContext = CommonPool, action: suspend () -> Unit) {
    val jobs = List(massive) {
        launch(context) {
            action()
        }
    }
    jobs.forEach { it.join() }
}

private object ThreadConfinement1: Callable<Int> {
    val counterContext = newSingleThreadContext("CounterContext")

    override fun call(): Int {
        var counter = 0
        runBlocking<Unit> {
            aMassiveRun(counterContext) {
                counter++
            }
        }
        return counter
    }
}

private object ThreadConfinement2: Callable<Int> {
    val counterContext = newSingleThreadContext("CounterContext")

    override fun call(): Int {
        var counter = 0
        runBlocking<Unit> {
            aMassiveRun {
                run(counterContext) {
                    counter++
                }
            }
        }
        return counter
    }
}

I time both callables 5 times to warm up hotspot and only take the last measurement. Both tests run all incrementation on a single thread but ThreadConfinement2 does the scheduling of the actual work in form the CommonPool. The timings measured are 3.5s for ThreadConfinement2 while ThreadConfinement1 takes 5.8s on my machine. Can anyone explain, why ThreadConfinement2 is faster? This came as a big surprise to me. Edit: Further measurements did not support these numbers. I now get more expected timings of 2.6s for ThreadConfinement1 and 4.3s for ThreadConfinement2. I guess my machine was just doing funny things in the background. Timing things correctly is never easy in a multitasking environment.