<@U0ZFBBUBU> with `kotlinx-coroutines-jdk8` you ca...

# coroutines

[elizarov]

@groostav with kotlinx-coroutines-jdk8 you can write something like:

val coercedResult = future { 
    try { result.await() } 
    catch(ex: Throwable) { 
        Thread.handleUncaughtException(ex)
        emptyList() 
    } 
}

[groostav]

elizarov: out of curiosity, if coercedFuture was a var, can you write coercedFuture = future { coercedFuture.await() }. It should right? The closure isn't going to capture changes in stack variables.

[groostav]

actually this can be trivially tested...

[elizarov]

Kotlin closures caputure vars as mutable vars

[elizarov]

Kotlin closures behave just like other { ... } block. If you mutate something from there, it mutates.

[groostav]

yeah, so that makes the code I wrote a kind of descheduled deadlock. Can a CoroutineContext provide enough info for cycle detection?

[elizarov]

can you elaborate on your problem?

[groostav]

@Test fun `when using mutable stack future var should properly snapshot in closure`(){
        //setup
        val initial = CompletableFuture<Int>()
        var ref = initial
        ref = future {
            ref.await() !!!! //this code deadlocks!
        }

        //act
        initial.complete(42)
        val result = ref.get()

        //assert
        assertThat(result).isEqualTo(42)
    }

[groostav]

causes deadlock

[groostav]

Im not thinking about a problem so much as a gotcha for newbies

[groostav]

im wondering if coroutines can programatically detect this behaviour, but I suppose that would only work for the future and await methods, not simply all coroutines generally

[elizarov]

it is hard to detect programmatically

[elizarov]

even Go is bad at detecting stuff like that

[elizarov]

also `var`s are evil.

[groostav]

yeah i know, but its a supported language feature, somebody is going to write production code like I just sent you

[groostav]

and be suprised by a deadlock

[elizarov]

there is plan

[groostav]

I'm also thinking a CoroutineContext check at the future and await boundaries should be sufficient

[elizarov]

Coroutines are not like threads. They don't even have ids. But in debug mode they do, so we might try to write some kind of dead-lock detector based on that.

[groostav]

something like

fun future(ctx: CoroutineContext){
  val newContext = newCoroutineContext(CommonPool + context + BlacklistFuture(future))
  //...
}
fun Future.await() {
  if(this in currentContext.blacklistedFutures.map { it.future) throw IllegalStateException("cyclic call to future!")
}

[elizarov]

This is an interesting idea. Could work!

[elizarov]

There also an IDE proposal to warn on that kind of var-capturing code: https://youtrack.jetbrains.com/issue/KT-15514

[groostav]

yeah its funny, I was driven nuts once or twice by java's "variable must be effctively final", but I suppose this is simply the other side of that coin

[elizarov]

Exactly