https://kotlinlang.org logo
Join Slack
Powered by
there are a lot of gotchas with channels where the...
# coroutines
w
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
Can anything be done to improve it? What do you think?
w
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
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
That is a much better reason, hehe
e
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
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
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
Does using broadcast channels help “need to stay open” problem? IMHO, broadcast channels is the closest thing we have to Rx now.
w
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
They are removed when all subscribers receive them.
d
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
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.
6 Views
Open in Slack
PreviousNext
Powered by