Why dont you execute immediately when on the ui thread already?

@elizarov I was thinking about the rx-java coroutine .await. I think it might make sense to create a wrapping class that encapsulates the error / sucess.

might make sense to create a wrapping class that encapsulates the error / sucess

@Paul Woitaschek I use this approach for my coroutine wrapper for Retrofit: https://github.com/gildor/kotlin-coroutines-retrofit#awaitresult

.await

returns sealed class Result

@elizarov why don't you include completable?

i fired up htop and noticed that when i execute the java program all CPUs’ hit 100% consumption while in kotlin programs they hit 91% or 95% and in between

But that whole start / stop / interrupt / post on UIThread logic is messy

But I have multiple modules, maybe its related to that?

Could someone quickly summarise it or point me to a doc where it is summarised, how kotlin coroutines are different from Quasar? They both seem to offer almost the same capabilities.

referenced in https://github.com/Kotlin/kotlinx.coroutines

@elizarov Will

kotlinx-coroutines

be published to jcenter? I’m updating library but still cannot use kotlinx-coroutines without

maven { url "<https://dl.bintray.com/kotlin/kotlin-eap-1.1>" }

@elizarov is the Async suffix the convention you’ve landed on?

and i dont understand

RestrictsSuspension

😞

@cypher121 I think that would actually not be a good idea. I think I would stumble a lot over trying to find a function I know is there, but not being able to find it, because I forgot to make the current function a suspend fun.

@kingsley Yes. It is inverted, though. Jobs can have multiple children and when a job completes, all its children are cancelled. So, instead of creating a composite subscription you just launch all the relevant coroutines as children of your job. In some respect every Job is a potential composite (can have an arbitrary number of children). You can read more and find an example in "Children of a coroutine" section of the guide: https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md

Here is a hint. You can read "Go concurrency patterns". Most of them directly translate to Kotlin coroutines.

Is there a good document that explains how coroutines in Kotlin work? It's fascinating how it's suspending without threads 😯

I have a setup like this one:

// File A: Some repository
fun fetchFooAsync = async(CommonPool) { ... }

// File B: Android activity
private val job = Job()

fun loadFooIntoUI() {
  launch(Android + job) {
    fetchFooAsync().await()
    ...
  }
}

When the activity in B is getting destroyed, I can easily call

job.cancel()

, and the coroutine in

loadFooIntoUI

is canceled correctly. However, the

fetchFooAsync

call still continues indefinitely. Is there a way to neatly cancel everything altogether without having to explicitly pass

job

to

fechFooAsync

?

The only other way I could do this is to add an

invokeOnCompletion

to the returned Job for

launch

, but that takes away the fun since I have to repeat it everywhere

I don't have to write boiler plate 😄 wow

The key advantage of coroutines is that they let you avoid callback hell. For example, you can replace deeply nested flatmaps with a simple and easy-to-understand imperative-style "do this, do that" code. If you don't have any of that and all your Rx code is just "take this IO result, switch to UI thread, display it" or "take this button click, then do some IO", then you will not find much difference between Rx and coroutines.

Is there any coroutine implementation for mysql/jdbc?

The most interesting part of Android is that it's main thread is just a special case of a general system. I would expect a first-party offering to be able to use any Handler, not just one wrapped around the main Looper.

Making it a class that can accept any Handler is easy. I'll do it. Naming the instance for the main thread is hard. I'll run a poll on Monday.

@elizarov Did you mean "Confine coroutine execution on a non main thread"? Coroutines are typically network or file stuff, they should be kept out of the the EDT

It is Ok, but under high load (lots of CPUs, lots of ops)

ConcurrentHashMap

is better.

And last thing. It is better not to use

Async

in the name of suspending function. This naming is better to be reserved for functions that start asynchronous operation and return immediately, usually with some kind of future/deferred result. The async part the name serves as a reminder to the invoker of this function that they should not ignore the result, but must await for it or compose it into a larger computation in some way. There is no such risk with suspending functions, and the async in their name is superfluous.

fetchData is something like firebaseReference.addValueEventListener(listener) in my real code. it is totally safe to call from UI thread. it registers callback that can be triggered many times. Also it is necessary to unregister callback when activity is destroyed or when we dont need updates anymore. so i need some mechanism to catch cancel event inside this method

fun dataChannel(context: CoroutineContext) = produce<Any>(context) {
        val listener = object : Listener {
            override fun onSuccess(value: Any) {
                offer(value)    // emit to channel
            }

            override fun onError(throwable: Throwable) {
                close(throwable)    // close channel
                //throw throwable
            }
        }
        addListener(listener)
        
        fetchData() // invoke callback's onResult here
        
        // need to register removeListener() somewhere
    }

Guys I just wrote an article on Kotlin coroutines https://medium.com/@zohaibhassan/in-pursuit-of-better-jvm-futures-kotlin-coroutines-281a79211b09#.npk9flsxm let me know if I messed up somewhere 😛