kotlinlang #coroutines

Do flyweight patterns exist in coroutines? For example, let's say I have 5 suspend methods that require a parameter, which can also be retrieved by a suspend method. If I call two of them simultaneously, is there a way for me to have them wait on the same suspension? One way of doing this would be to keep a map of keys to deferred values, where I assume that calling await twice will only run the logic once. Is there a better way of achieving that?

bj0

09/27/2018, 8:51 PM

caching the value?

muralimohan962

09/28/2018, 6:02 AM

Can anyone point me to some comprehensive resources on how coroutines are implemented under the hood?

orangy

09/28/2018, 6:08 AM

https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/coroutines-guide.md

Darshan Mistry

09/28/2018, 7:10 AM

Hello all, Any good article or video to learn coroutine. Currently, I am referring github documentation (https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/basics.md)

spand

09/28/2018, 9:01 AM

Has kotlin versions of Guardedby, Immutable, NotThreadSafe and ThreadSafe annotations been considered ? With associated compiler / ide support that is ?

louiscad

09/28/2018, 1:55 PM

Hi, am I right that there's no way to distinguish whether a

CancellationException

is caused by a function call or by the cancellation of the coroutine scope? I'd like to handle cancellation caused by a function call without stopping suspending iteration, unless the whole scope is cancelled (because the Activity is destroyed)

:thread-please: 1

Paul Woitaschek

09/28/2018, 2:41 PM

Now with kotlinx.coroutines 0.27.0 I receive the following proguard warning:

Vsevolod Tolstopyatov [JB]

09/28/2018, 5:49 PM

📣 📣 📣

kotlinx.coroutines

version

0.30.0

. We are happy to announce the last release for Kotlin 1.2.70 and the last

0.x.x

release. The next release will be 1.0.0-RC for Kotlin 1.3-RC and all deprecated API will be removed. Changelist: * [Major]

async

and async-like builders cancel parent on failure, making parallel decomposition completely exception-safe. No more unnecessary

awaitAll

in structured concurrency! * [Major] Coroutine scheduler is used for

Dispatchers.Default

instead of deprecated

CommonPool

. * Supervisor job and supervisor scope for more controlled cancellation of coroutines hierarchies. *

Job()

with parent now also cancels parent on failure consistently with other scopes. * Various bug fixes and improvements. See the full changelog here: https://github.com/Kotlin/kotlinx.coroutines/releases/tag/0.30.0. To properly prepare your application to 1.0.0 release, do the following steps: 1) Update

kotlinx.coroutines

0.30.0

version. 2) Inspect compiler warnings about deprecated API and migrate it to a proposed alternative. Most of deprecated API has a corresponding replacement which can be applied from IDEA with quickfix. 3) Update Kotlin version to 1.3-RC and

kotlinx.coroutines

0.30.0-eap13

. 4) Update

kotlinx.coroutines

1.0.0

when it’s released 🙂 Compatibility and migration policy: https://github.com/Kotlin/kotlinx.coroutines/blob/master/COMPATIBILITY.md

🎉 14

apomelov

09/28/2018, 6:10 PM

Hi. I'm trying to understand coroutines a bit deeply, but missing some materials for the very beginning. I heard that coroutines are much "cheaper" than threads. Sounds nice. Does it mean that I shouldn't use threads anymore? Each time I want to run some parallel computation I use coroutines instead of threads now?

alex009

09/29/2018, 1:57 AM

hello! after update multiplatform (ios & android) module to kotlin 1.3 RC with coroutines to 0.26.1-rc-conf2 i got on ios error IncorrectDereferenceException, stacktrace in thread

elizarov

09/29/2018, 3:57 PM

📣

kotlinx.coroutines

version

0.30.0-eap13

for Kotlin

1.3.0-rc-57

(can be used from

1.3.0-rc-116

, too) & Kotlin/Native

0.9.2

thevery

09/29/2018, 10:55 PM

With new SC, is there any changes in

withContext

async

policy or it is ok to continue using

withContext

CoroutineScope

sample uses

async

, not `withContext`: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.experimental/-coroutine-scope/index.html

louiscad

09/30/2018, 12:28 PM

Does calling

coroutineContext.cancel()

for a

suspend fun

immediately throws

CancellationException

to interrupt the execution of the function, or should I call

yield()

afterwards?

pakoito

09/30/2018, 12:35 PM

suspended functions run synchronously until the first suspension point

mayojava

09/30/2018, 4:45 PM

are there any major difference between

<http://Dispatchers.IO|Dispatchers.IO>

and

Dispatchers.DEFAULT

that one needs to know about

vaskir

10/01/2018, 11:00 AM

Is it possible to run an

actor

on a dedicated Dispatcher (e.g. the IO one)?

vaskir

10/01/2018, 11:31 AM

I cannot find https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/exception-handling.md#supervision-job in

0.26.1-eap13

vaskir

10/01/2018, 12:02 PM

Another example is a server process that spawns several children jobs and needs to supervise their execution, tracking their failures and restarting just those children jobs that had failed.

I cannot get my head around how to restart a children (say, an

actor

) from inside a
CoroutineExceptionHandler
😞 What I really need is just restarting strategy a-la Akka.

fun CoroutineScope.worker(ctx: CoroutineContext) = actor<Int>(ctx) {
    for (msg in channel) {
        println("got $msg")
        if (msg == 2) throw Exception("it's $msg and we are failing")
    }
}

GlobalScope.launch {
    val supervisor = SupervisorJob()
    var actor: SendChannel<Int>?

    val handler = CoroutineExceptionHandler { _, _ ->
        {
            actor = worker(coroutineContext + supervisor + handler) // error: handler is not defined
        }
    }

    actor = worker(coroutineContext + supervisor + handler)

    for (msg in 1..5)
        actor?.send(msg)
}

miguelsesma

10/01/2018, 12:40 PM

Any idea?

elizarov

10/01/2018, 1:13 PM

@minivac The proper and idiomatic way is to never use

Deferred

as your return type. Write a suspending function instead:

suspend fun doSomething(param: Int): Something {
   code ...
}

See how much more concise it is!

louiscad

10/01/2018, 3:18 PM

Hi, is there a way to cancel/close a

ReceiveChannel

without clearing its buffer? I'd like to stop an underlying items generation, and get what was processed so far as a list. I used

cancel()

in the past, but it seems it now clears the buffer, and I'm looking for an alternative.

uhe

10/01/2018, 3:35 PM

I'm a bit confused by the new scoping mechanism. I'm trying to migrate some coroutine-based code and stumbled upon this:

@Deprecated("No replacement. Group child in a coroutineScope { } block to wait for them")
public suspend fun Job.joinChildren()

However, I don't see how to "group child in a coroutineScope". For example:

val networkContext = <http://Dispatchers.IO|Dispatchers.IO>
val networkJob = Job()

private fun onNetworkContext(block: suspend CoroutineScope.() -> Unit) =
    GlobalScope.launch(networkContext + networkJob, block = block)

// invoked from another coroutine:
suspend fun abortAndRetry() {
    networkJob.cancelChildren()
    // how do I replace this properly?
    networkJob.joinChildren()
   // retry ...
 }

nerses

10/01/2018, 8:15 PM

repeat(1000) { loadAndCombine() }

will take 1000 seconds

repeat(1000) { launch { loadAndCombine() }}

will take 1 second my question is whether wrapping it with

launch

is the “correct” way of doing this

fabiocollini

10/02/2018, 6:33 AM

hi everyone, I am trying to use the

produce

method to create a channel inside a suspending method but I have some problems. I have a different behaviour defining my method as

CoroutineScope

extension method and using

coroutineScope

inside a suspending method. These are the two versions:

private fun CoroutineScope.produceExtension(): ReceiveChannel<Int> = produce {
    send(1)
    send(2)
    send(3)
}

private suspend fun produceCoroutineScope(): ReceiveChannel<Int> = coroutineScope {
    produce {
        send(1)
        send(2)
        send(3)
    }
}
`

Using the second method I am not able to use the channel (the method never ends), I have already opened an issue with the complete code here https://github.com/Kotlin/kotlinx.coroutines/issues/645 Am I doing something wrong? Should the two methods be equivalent?

Vsevolod Tolstopyatov [JB]

10/02/2018, 1:59 PM

📣 📣 📣

kotlinx.coroutines

version

0.30.1

. This a maintenance release. Main change is that Android

Main

dispatcher is now available as

Dispatchers.Main

. It fixes issue with Android Studio (#626) and allows users to safely migrate to

0.30.1

without any tooling issues. Full changelog: https://github.com/Kotlin/kotlinx.coroutines/releases/tag/0.30.1

:android: 3

🎉 5

❤️ 1

Ian

10/02/2018, 5:41 PM

Trying to use the latest coroutines in the 1.3 EAP, but I keep getting this error on a call to `runBlocking`: https://slack-files.com/T09229ZC6-FD51JHCQZ-7d48808590

Ian

10/02/2018, 5:44 PM

From my reading, it’s due to SuccessOrFailure changing to something else in the EAP, but I’m not sure how to fix it. Should I be using something other than

runBlocking { }

now?

Hamza

10/03/2018, 3:28 AM

when i have this code:

launch {
...
}

is this async? because i want to have some stuff done async, and then after the async, i want to go back to the main thread and call a sync function

mayojava

10/03/2018, 6:59 AM

fun main(args: Array<String>) = runBlocking<Unit> {
    try {
        failedConcurrentSum()
    } catch(e: ArithmeticException) {
        println("Computation failed with ArithmeticException")
    }
}

suspend fun failedConcurrentSum(): Int = coroutineScope {
    val one = async<Int> { 
        try {
            delay(Long.MAX_VALUE) // Emulates very long computation
            42
        } finally {
            println("First child was cancelled")
        }
    }
    val two = async<Int> { 
        println("Second child throws an exception")
        throw ArithmeticException()
    }
        one.await() + two.await()
}

it doesnt seem to work for me. The parent coroutine still blocks waiting for the first

async

after the second threw the exception

Title

mayojava

10/03/2018, 6:59 AM

fun main(args: Array<String>) = runBlocking<Unit> {
    try {
        failedConcurrentSum()
    } catch(e: ArithmeticException) {
        println("Computation failed with ArithmeticException")
    }
}

suspend fun failedConcurrentSum(): Int = coroutineScope {
    val one = async<Int> { 
        try {
            delay(Long.MAX_VALUE) // Emulates very long computation
            42
        } finally {
            println("First child was cancelled")
        }
    }
    val two = async<Int> { 
        println("Second child throws an exception")
        throw ArithmeticException()
    }
        one.await() + two.await()
}

it doesnt seem to work for me. The parent coroutine still blocks waiting for the first

async

after the second threw the exception

Vsevolod Tolstopyatov [JB]

10/03/2018, 1:18 PM

Have you updated your coroutines version to 0.30.1?

Dico

10/03/2018, 2:57 PM

The reason is that the

two

coroutine doesn't throw its exception until you call

two.await()

which doesn't occur until

one.await()

returns.

If the exception thrown by

two

is supposed to cancel the parent before

await()

is called then I guess I don't know.

Vsevolod Tolstopyatov [JB]

10/03/2018, 10:03 PM

@Dico this behaviour was changed in the latest realese

➕ 1

View count: 5