I hope someday channels will be bound to coroutine lifecycles and we no longer need explicitly do c...

# coroutines

[Antanas A.]

I hope someday channels will be bound to coroutine lifecycles and we no longer need explicitly do coroutineContext[Job]!!.invokeOnCompletion { broadcastChannel.close() }

[gildor]

But you already shouldn't do this

[gildor]

What is your use case, how do you use this btoadcast channel? Because if you use comsumeEach no need to do this
Or even better to use Flow which make leak even harder

[gildor]

Just replace openSubscription with asFlow

[Antanas A.]

the use case is that one module uses single channel from another module. And that module needs hook to that channel multiple times (in module), and also provides new single channels to other modules.

class Module(inputStream) { 
    val broadcast = inputStream.broadcast()
   // multi usage: launch { broadcast.consumeEach { ... } }
    fun output() = broadcast.openSubscription().map(...)
}

It's all ok with a consumeEach as you said, but it's not ok with channels which is returned by output() function

because they are outside of controllable scope of a module

[Antanas A.]

would be nice, that broadcast() will be suspend fun and bounds to parent's coroutine context

[Antanas A.]

it's one of examples, but we've noticed that we are carefully controlling coroutines lifecycles

[Antanas A.]

and in parallel there is a need to control all channels "lifecycles"

[Antanas A.]

it would be easier that all channel related stuff will be bound automatically to coroutine lifecycles (as channel is implicitly a coroutine also)

[Antanas A.]

and there is a case that broadcast() will connect to inputStream channel and consumes from that forever

[gildor]

Just use Flow

[gildor]

You cannot start it without suspending, so it more safe

[gildor]

Also it has more operators, so maybe you can write it in a more simple way

[louiscad]

Using asFlow for a BroadcastChannel will not solve the issue as a BroadcastChannel stays hot while it's not been explicitly closed with close().

[gildor]

@louiscad Yes, you right, I see now
The problem of this code is inputStream, not even broadcast channel actually, broadcast channel just used to close input stream, and I'm not really sure that it's correct enough

[gildor]

If you want to reuse scope, invokeOnCompletion is fine imo, you can even write extension function to simplify attaching of resources (or even Closables) to scope

But I really don't think that it is problem of Channels

[Matej Drobnič]

This is probably related: https://github.com/Kotlin/kotlinx.coroutines/issues/1086

[Matej Drobnič]

I think your use case should be handled by flow, but flow does not support that yet.