core-async 2022-10-13 | Slack Archive

vlaaad10:10:31

Is an ordinary chan that receives 1 value and is then closed better than promise-chan? It looks like the former better represents semantics of receiving a value and then stopping than the latter. Not sure when to use what…

Ben Sless11:10:49

You use a promise chan if you want the value to stay there forever. A regular channel, once you read from it, will not contain that value anymore. Take once or take many times?

vlaaad12:10:59

Yeah, that’s the difference between them, but what are the implications from that?

vlaaad12:10:16

For example, using read-once chans, if you have multiple services to ask the same question, you can send requests to every one of them and a/merge response chans, and now we have a chan that contains all responses and then closes. That’s useful. What about promise-chan? Where I can use that?

Ben Sless15:10:04

A promise chan is a good use case for a result of async effect, like http call.

vlaaad15:10:26

Can someone explain how to arrange a chan closing? Existing chan combinatorics seem to close downstream when upstream closes, but when the downstream closes, they only stop consuming from upstream without closing it. What are the consequences of this behavior? Should I strive for the same behavior when writing my own go loops that do similar consumption from upstream/feeding the downstream processing? What if I close upstream when downstream closes?

Ben Sless15:10:26

You can test puts on the downstream channel. They return false if it's closed. Then you can decide what to do, either propagate closing upwards or leave it hanging

vlaaad16:10:43

the question is, when to do what

vlaaad16:10:17

My understanding is: if someone else might consume from upstream, we should leave it hanging so processing can continue. If no one else can consume from upstream, we should close because otherwise we will be just filling up the buffer for a while without any resolution possible. Correct?

2022-10-13

Channels