How do I properly send to a `SendChannel` which might be clo

Question

How do I properly send to a `SendChannel` which might be closed Do I have to just catch the `ClosedSendChannelException`

Jonathan · Answer

If it is closed you cannot send elements to it by definition So yes you just have to catch the exception and deal with it

diesieben07 · Answer

Ok Then maybe I am going about this wrong I have a potentially infinite source and I want the receiver to be able to tell hey I don t need anymore Is `close` the correct way

Jonathan · Answer

If you don t want elements it is okay to close it But of course it won t be infinite anymore Note that you can also test `isClosedForSend` to know if it is currently close

Jonathan · Answer

Or depending on your use case you maybe are looking for a `BroadcastChannel`

Jonathan · Answer

If using a broadcast you would never close the broadcast but the receiver could close the opened subscription

diesieben07 · Answer

Yes I can test `isClosedForSend` but that s a race condition is it not tocttou

diesieben07 · Answer

Well I need to close the channel because there are resources associated with it network stuff

Jonathan · Answer

Then If possible I would recommend to create the channel with `produce` this function will handle everything like closing when done when cancelled and when failed

diesieben07 · Answer

That only moves the problem does it not The channel still has no `sendIfPossibleOrReturnFalse` method

diesieben07 · Answer

If so I could just do ``` do val element = TODO compute next element while channel sendIfPossibleOrReturnFalse element ```

diesieben07 · Answer

That s what I am trying to achieve

Jonathan · Answer

Do this instead ``` produce while isActive val element = TODO send element ``` Then `produce` will handle it for you

diesieben07 · Answer

Will it though What if the receiver closes the channel during whatever `TODO` is Then `send` will throw

Jonathan · Answer

If the consumer cancel the channel `send` will throw a `CancelledException`

diesieben07 · Answer

Yes

diesieben07 · Answer

Which I do not want I want the receiver to be able to tell the producer to stop

diesieben07 · Answer

I do not want the receiver to be able to tell the producer to blow up with an exception

diesieben07 · Answer

Also with this `produce` approach how do I terminate the underlying thread `newSingleThreadContext` when the channel is closed

Jonathan · Answer

`CancelledException` will be consumed by `produce` as it is a normal reason to be terminated If you use resources you should anyway always ensure they are closed in case of exception same as if you wouldn t use coroutines

diesieben07 · Answer

Okay so then that part is sorted How do I close the thread context though

Jonathan · Answer

If you use `newSingleThreadContext` you have of course to ensure that is terminated even in case of exception

diesieben07 · Answer

Yes but how can I terminate it from inside the produce Can I terminate it from inside itself

diesieben07 · Answer

Just `use` will not work will it

Jonathan · Answer

Mmh that s a good question I ve never did that

diesieben07 · Answer

I e this ``` newSingleThreadContext use ctx gt return produce ctx ``` won t work right

Jonathan · Answer

no it won t work

Jonathan · Answer

It may terminate the dispatcher to early

diesieben07 · Answer

Yeah that s what I was thinking

diesieben07 · Answer

I guess I will have to pass the context into the method that returns `produce`

Jonathan · Answer

``` fun startProducer val context = newSingleThreadContext my dispatcher val result = produce context context use send 1 send 2 send 3 ```

Jonathan · Answer

this should work But I wonder if there is a better way of doing it

diesieben07 · Answer

I am doing it outside now and passing `coroutineContext` as a parameter

diesieben07 · Answer

thanks for your help

Jonathan · Answer

By the way it may be not necessary in the future to terminate the dispatcher see <https github com Kotlin kotlinx coroutines issues 261>

bj0 · Answer

why does it need to be outside produce ``` produce newSingleThreadContet dispatch use while isActive send TODO ```

Jonathan · Answer

< bj0> in your example `produce` use `CommonPool`

bj0 · Answer

ah right

bj0 · Answer

you can toss a `withContext` in there

bj0 · Answer

outside the `while` loop

Jonathan · Answer

Yes indeed But it is simpler to simply give the context as an argument of `produce`

bj0 · Answer

I don t know I think it s less simple to have to create an essentially local variable outside the scope of where it s used

bj0 · Answer

seems leaky

Jonathan · Answer

Yes but if it is really local what is the point creating a single thread context Why not simply use the common pool

Jonathan · Answer

I don t see the point of creating a thread pool if it is not to be shared by many coroutines

bj0 · Answer

thats an implementation detail and I don t know what his program s context is

Jonathan · Answer

I m not sure I feel that s there is something not correct with this approach Basically it could leads to a lot of thread creation which is very expensive and bad practice The good practice is to use thread pool in order to reuse the threads I would rather create a global ThreadPool like `val MyThreadPool = newSingleThreadPool my thread pool ` and use it for the whole life of the application calling `produce MyThreadPool `

diesieben07 · Answer

Yes I agree with < Jonathan> That s why I ended up passing the `CoroutineContext` into my own method and then pass it on to `produce`

bj0 · Answer

if you re doing that you re not going to clean it up when one producer closes though

diesieben07 · Answer

I have the whole thing produce and consume in a `newSingleThreadContext use ` It is closed properly

bj0 · Answer

i mean if you re going to create a global and use it for the whole life of the application obviously use case matters