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

Can anything be done to improve it? What do you think?

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.

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

.

That is a much better reason, hehe

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….

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.

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?

Does using broadcast channels help “need to stay open” problem? IMHO, broadcast channels is the closest thing we have to Rx now.

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?

They are removed when all subscribers receive them.

But when you only have one subscriber, isn't it inefficient? Especially w/ events that could be very numerous...

I am using broadcast channels with MVI pattern and never had any problems with prematurely closed channels