Googled a bit but haven't found any issues so far

because the state machine is inlined whereas Rx encapsulates them (and you aren't counting them)

at the moment we only have operator fusion in IO for Map. Most other datatypes are eager, but I can see it working for stuff like Reader or Free.

the actual count of the Rx code you pasted is on the order of 50 methods

maybe close to 100

i suspect the coroutine code is around 50 as well

100 is just initial overhead (see notice about 2.5k/0.5k above), I'm comparing incremental addition

it's not a fair comparison

map and filter in coroutines is free, for example

in Rx you pay for the method reference or lambda

i can create 6-line samples that make Rx look like the bad guy fairly easily

i'm looking into the bytecode now but it's 6 o'clock and i think i'm going to defer this for another time. i'm not saying that there isn't room for improvement, but i don't think it's a cut and dry and coroutines are worse right now. it's a different level of abstraction than Rx so it's not going to compare directly.

How would one write a test to check that a race condition between coroutines is correctly managed?

Unfortunately, testing that concurrency issues do not exist is very difficult.

For instance, on x86, some things allowed by the java memory model simply will never happen because the hardware has a fairly strong memory model

thread-weaver or awaitility might be of some use

give each coroutine an optional delay parameter, then run them 1000 times with seperate randomized delays?

Unfortunately, races may need many billions of executions to trigger once, and most amounts that you could delay with things like sleep() are orders of magnitude too large 😞 http://openjdk.java.net/projects/code-tools/jcstress/ is one approach

you haven't demonstrated that it's a problem

optimizing for a case without suspension doesn't really make sense

is there a coroutine primitive which waits for a flag to be set?

you could use Kotlin

observable

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.properties/-delegates/observable.html

I just worry that people often concider "best practices" as "the only docs that I have to read". I mean there are many parts of Kotlin coroutines and Kotlinx coroutines especially that hard to put to a short "best practices", maybe "Common pitfalls" would be good too, like infamous "why blocking CommonPool is bad", but all those things are actually will change soon (with shared pool dispatcher) Also maybe make sense to invest to shorter version of guide for beginners, but honestly not sure why Coroutine Guide by example is not enough for this. But maybe would be nice to separate channels to a separate doc (separate lib?) and also improve channels docs with examples of common patterns One more useful thing would be a document that uses RxJava as example for explaining coroutines what is different, how to replace some operators and so on, just because it's most popular lib for async programming at least on Android

I’m trying to use channels to read lines from a file, process these lines using several threads (since this processing step is slow), and then write the result to a single file - so it’s a “fan out” followed by a “fan in”.

I’ve got it working, except that it hangs when the file has been completely read, rather than stopping and closing the output file.

Here is an example I’m playing with - it just produces two numbers and then stops. https://gist.github.com/sanity/75d7b28b1e7690879020285631435d99

@Ian shared a file: gistfile1.txt

joinChildren

doesn't wait for the parent job, and your

launch

job has no children

@bj0 Appreciate it, how should I be structuring this? I’m confused by where I should use

launch

versus

runBlocking

, and so on.

I guess I should be executing

doubler()

from multiple threads too, also a bit confused here. In the docs it uses

repeat(n) { }

to launch multiple processors in different threads.