sad to see it's just nio's APIs

i have a project i’d like to prototype using the I/O library once there’s a socket backend

@gildor could you please explain why we need this extra code in each coroutine in the

kotlin-coroutines-retrofit

lib?

private fun Call<*>.registerOnCompletion(continuation: CancellableContinuation<*>) {
    continuation.invokeOnCompletion {
        if (continuation.isCancelled)
            try {
                cancel()       // why to cancel already cancelled coroutine?
            } catch (ex: Throwable) {
                //Ignore cancel exception
            }
    }
}

regarding hot vs cold, there is no concept of a cold Channel is there? My best bet is to give something like a

Provider<Channel>

@jw A coroutines threading model is different from Rx threading model. In Rx the thread your code runs in is implicitly controlled by various onXXX operators up/down the stream, while in coroutines the thread (context) is explicitly specified for each coroutine. The only exception is

Unconfined

context, which leaves the thread “unspecified”.

@deviant

EmptyCoroutineContext

and

Unconfined

are virtually the same with the exception that

Unconfined

is designed to work with debugging facilities of

kotlinx.coroutines

(in debug mode you’ll get the id of the executing coroutine added to the thread name — wastes a lot of CPU, but simplifies debugging)

can we get something like

ChannelIterable

that has

fun iterator(): ChannelIterator<T>

?

@anthonyandroid Please check this section of official coroutine guide - https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#concurrent-using-async Also you can check sample from kotlin-coroutines-retrofit (you can use this approach for any coroutine): https://github.com/gildor/kotlin-coroutines-retrofit#parallel-requests

Let me offer this conceptual model:

launch

is just like starting a new thread. If the code inside

launch

crashes with exception then it is considered “uncaught” exception and, generally, should crash your app (on Android that happens automatically). However, when you use

async

and the execution results with exception, then this exception gets stored inside the

Deferred

. It is your obligation to process it later. So: -

launch

- fire and forget, crash application on uncaught error; -

async

- launch and

await

for result later. You must

await

on a coroutine that you’ve created with

async

. You MUST NOT forget about the coroutine you’ve started with async.

It would be nice to have it in kdoc of launch: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.experimental/launch.html

The only reasons we don’t have a wiki for

kotlinx.coroutines

is because we are still evolving it and bits of syntax and behavior might change from release to release. It is easier to keep docs versioned together with sources (both guides and kdocs). You cannot do this with wikis. Risks are high you will end up with outdated wikis (for example,

CoroutineScope.context

was deprecated recently, renamed to

coroutineContext

— it was easy to push it into all the guides and kdocs with a single commit)

📣 I’m working on a change to the behavior of parent-child relations between coroutines for the upcoming release of

kotlinx.coroutines

. Parent will always wait for its children to complete. Details of the change are here: https://github.com/Kotlin/kotlinx.coroutines/issues/125 Please, comment if you don’t think it is a good idea.

oh, never seen some non blocking IO actually, what would it look like for example on android?

Not sure if Kotlin has something similar to

blocking

but if not you should probably create a Pool that is tunned up for this type of ops usually DB calls, network IO, etc...

@kevinherron It will not deadlock. Cancelling parent immediately cancels children, it then waits for them to complete. Moreover, since children receive from parent’s channel in your case, if parent terminates normally, then it closes its own channel (first!), thus aborting all receiving children, and then waits for its children to complete.

just curious: what is the best way to convert

Channel

into

Sequence

? is it possible? something like that

produce<Int>{
 send(1)
 send(2)
 send(3)
}
.asSequence()  // some suspendable helper?
.filter {it==1}

In a way, yes, the code I'm targeting are game scripts which maintain a lot of state about their last execution which results in lots of tiny complex state machines. This reduces that complexity significantly!

@dragas There is no reason to use coroutines unless you have any suspending (async) function. If it all just CPU-bound, the coroutines offer a little help/improvement. For CPU-bound task, like parallel collection processing, Java8 streams work best. Coroutines are designed for tasks that wait for something most of the time.

There are 2 sides to your question. Can we unit test

launch

? Yes, we can. You simply run it within a

runBlocking

and

await

it’s completion (or termination as the case may be) However the

UI

makes it difficult to unit test without bringing all the platform dependency with it. I would abstract this part out instead, to make it easy to swap with a non-platform dependent coroutineContext

You create a channel and run

N

worker coroutines that all take tasks from this channel and do your http calls. The number of coroutines you have limits the number of concurrent HTTP requests without having you think about threads at all. In fact, if your HTTP library is truly async, they can all simply run a single thread, yet still giving you control over maximal concurrency.

@Deactivated User you should create an issue

As long as coroutines are experimental i would not recommend. But If youchose to go with coroutines without rx i would love to hear about the experience and you should definately write a blog about it 🙂

It’s not a good idea to use CommonPool for blocking IO operations

Do I need to call bindImage().await?

You can always add

run(UI)

for them just to make sure they are on the right thread (it will not switch if you invoke them from the right thread). Ideally, we should have tooling where you’d annotate your UI functions with

@UI

(or even better — make this annotation inferred by looking at their code and seeing that they use some other UI-thread-only functions) and then it would warn you if you try to use them from the wrong context…. Just an idea.

Ah nice, got confused with the autocompletion to

kotlin.run

Where was the thread on changing

run

builder function function to a less confusing name? Gonna vote on that

message has been deleted