https://kotlinlang.org logo
#coroutines
Title
# coroutines
w

withoutclass

06/12/2018, 2:29 PM
there are a lot of gotchas with channels where they are shut down unexpectedly, until you dig into the doc and see that it says that’s what will happen
e

elizarov

06/12/2018, 3:05 PM
Can anything be done to improve it? What do you think?
w

withoutclass

06/12/2018, 3:07 PM
I asked earlier about providing a
forEach
complement to
consumeEach
, I’d be happy to put up a PR for it, but it seemed the thinking was that this is how JB would prefer the design to be to avoid confusion.
It seemed a bit counter-intuitive to me that the channel being read from would be automatically closed if the coroutine consuming it was canceled.
The kdoc clearly says this though, so it was my fault for not reading the documentation
e

elizarov

06/12/2018, 3:10 PM
The original plan was to have
forEach
as a function that you can use invoke some suspending function on each element. We wanted to have it as extension on all the Rx streams, too, but Rx already has
forEach
which only takes non-suspending function as parameter, so it was renamed to
consumeEach
.
w

withoutclass

06/12/2018, 3:10 PM
That is a much better reason, hehe
e

elizarov

06/12/2018, 3:12 PM
The fact that
for
loop does not consume the incoming channel makes it all really inconsistent. The question I’d ask here is whether we need to support
for
loop at all. Maybe
consumeEach
is the only operator we shall support (no for loops).
for
loop support is a good blowback to Go (and just like in Go it does not consume anything), but I really question its value….
w

withoutclass

06/12/2018, 3:15 PM
A lot of this is stemming from me trying to use channels as a replacement for Rx. So in my current scenario, I am reading bluetooth packets in from a service, and publishing those packets to a channel. I do not want these channels to ever close, since I’m only creating them once inside my scanning service. I need to be able to read from these channels in multiple places (activities), and when I leave an activity, I need to shut down the coroutines associated with the activity. Talking through it, I could probably re-design the service to create new channels whenever I bind to it, but this is just where I am currently.
d

dave08

06/12/2018, 3:45 PM
Same here, @elizarov, a bunch of use cases are counting on a channel staying open, for lets say, the life of an Android Activity to bridge the view layer to the business logic layer. This was a very nice thing in Rx, and every time we need to do it in Coroutines, we have to be aware of this catch... We had a few discussions here about a 'Best Practices and Pitfalls' page in the docs that would be tremendously helpful... I'm sure once people are more aware of them and the technical implications of them, you'll get more productive feedback on what needs to be changed. Also a lot of this information is spread out in various issues on Github and nobody (probably because everyone's so busy...) is there to put it all together. A few days ago, I mentioned that @Deactivated User is doing a great job on Ktor docs... he might be a good candidate, what do you think?
💯 1
e

elizarov

06/12/2018, 4:54 PM
Does using broadcast channels help “need to stay open” problem? IMHO, broadcast channels is the closest thing we have to Rx now.
w

withoutclass

06/12/2018, 5:03 PM
For me it’s probably the right decision to move to broadcast channels, since I can open/close subscriptions. Though I had some hesitation around the capacity of the channel. Are items removed from the
BroadcastChannel
when any subscribers receives items?
e

elizarov

06/12/2018, 5:14 PM
They are removed when all subscribers receive them.
d

dave08

06/12/2018, 5:16 PM
But when you only have one subscriber, isn't it inefficient? Especially w/ events that could be very numerous...
Also, chaining of multiple channels, with fan in fan out and vise versa is I think more convenient with
produce
...
g

giso

06/12/2018, 7:01 PM
I am using broadcast channels with MVI pattern and never had any problems with prematurely closed channels
Though the boilerplate could be reduced a little, I suppose.
2 Views