You mean use

runBlocking

in test function to wrap my original code which uses

launch(CommPool)

?

@elizarov I haven't seen the MainThread or UiThread annotation very often, but I'd say others are pretty common (Nullable, NonNull, IntDef...)

AndroidDispatcher.Main

?

Primary

?

Actually UI is more correct than main thread since you can technically have different main and UI threads (although it won't happen in end-user applications)

is there any type of

Iterable<T>.forEachConcurrently

?

@elizarov I remember you were working on document for UI programming

@elizarov In the coroutines GUI guide, is event conflation something that will come out in the next release?

How would you do callback bridging with coroutines? It's fairly common to do something like that to convert listeners to Observables in Rx

Since okhttp uses thread pool, it won’t give you much in terms of throughput…

With all of the innovation and standards that have gone into Reactive Streams lately, what is the main benefit of using coroutines instead?

what is the main benefit of using coroutines instead?

non-blocking code? 🙂

can Breadth First Search be simplified with coroutines? eg if i have a tree of `Node`'s where I want to do a BFS for a node that passes a certain

Predicate<Node>

, can I use a

suspend fun

to avoid all the queue

offer

and

remove

malarky?

@elizarov does kotlinx-couroutines have a mechanism for automatically unsubscribing observables, e.g. when the enclosing activity finishes?

@elizarov wouldn't it make sense to check if the current thread is the desired thread before calling

<http://handler.post|handler.post>(block)

in

HandlerContext

?

I'm getting

Warning:Ignoring Android API artifact com.google.android:android:2.3.1 for debug

. Can the dependency in kotlinx-coroutines-android be declared as compile time only so that the warning disappears?

@elizarov Good catch, thanks! Right now I'm only calling it from UI thread, but who knows what else I'll do with it once I have forgotten about that. I've updated the snippet, is it sufficient like that or does the standard synchronization not play nice with coroutines in some way?

Nice talk about what is under the hood of llvm coroutines:

I’m really curious will guys from kotlin-native team reuse native llvm implementation in the future or will create new one

The problem of “waiting forever” in the case of @uhe example of is called “communication deadlock”. It is not directly related to coroutines. It can happen with any channel-based communication abstraction, like distributed apps. It is not a big problem in practice if you follow established patterns on structuring your communication pipelines

val channel = Channel<Int>()
    launch(CommonPool) {
        delay(50)
        println("Closing and flushing channel")
        channel.closeAndFlush()
    }
    (0..3).map { number ->
        launch(context) {
            println("Sending $number")
            channel.send(number)
            println("$number sent")
        }
    }.forEach { it.join() }
    println("Done!")

which prints:

Sending 0
Sending 1
Sending 2
Sending 3
Closing and flushing channel
0 sent
1 sent
2 sent
3 sent
Done!

Released

kotlinx.coroutines

version

0.14

with significant fixes related to reactive stream modules. Change log is here: https://github.com/Kotlin/kotlinx.coroutines/blob/master/CHANGES.md

I just gave a try to https://github.com/gildor/kotlin-coroutines-retrofit Very nice!

are there any best practices how to debug coroutines/channels in idea/AS debugger? for example, how to determine the amount of currently running coroutines?

@elizarov given that using a job is the idiomatic approach to cancelling all running coroutines when a component is being destroyed, for instance. Should there be a method to cancel all child jobs but keep the parent job alive? Something like

clear

and

cancel

on a composite disposable in Rx I have a situation where the parent job should live longer than it's children.

did this example: https://github.com/nickymoelholm/smallexamples/blob/master/springboot-kotlin-playground/src/main/kotlin/com/moelholm/MessageClient.kt

hi guys! i'm going to implement coroutined version of

list.forEachIndexed

. i need the items order to be preserved, but each item should be processed in a separate thread (pool of 4 threads). is it a good idea to implement it via channels?

https://www.philosophicalhacker.com/post/why-im-skeptical-about-kotlin-coroutines-for-android-development 🙈

btw, i've just finished migration

rx -> coroutines

in one of my projects. totally happy so far 🙂