Fork me on GitHub
#core-async
<
2019-06-26
>
colinkahn22:06:01

When handling values from a channel, is it correct that when the channel closes the value will be nil? And, is it common to have to cover that case for each go block? For example if I have a go-loop and a channel i’m consuming returns nil I would stop recuring that loop?

ghadi22:06:31

yes, very common

ghadi22:06:14

@colinkahn also common to use some? as the predicate so that you can send any value including false over the channel (but not nil)

colinkahn22:06:33

would you use some? when building the channel? Like (a/chan (filter some?))

ghadi22:06:12

when reading it

ghadi22:06:40

as your recur condition

colinkahn22:06:15

Ah ok, so like a (when-some [x (a/<! my-chan)] ...) should suffice

ghadi22:06:49

the channel already rejects nil values when putting them in -- you shouldn't try to duplicate this "in userspace"

colinkahn22:06:29

gotcha, and even with the filter it’ll still emit nil upon close, if I understand correctly

noisesmith22:06:08

no, your code would just be stopped indefinitely reading nils

noisesmith22:06:14

and probably pegging the CPU

colinkahn22:06:46

oh alright, so yeah, I have to handle the nil case to break the loop

noisesmith22:06:54

or maybe I misunderstood you: the channel keeps making nils as fast as you ask for them, filter would just drop them all before other code sees them

dpsutton22:06:27

I'm not sure how impactful it is. But the timer's skiplist in cljs is just a simple linked list not a skip list. https://clojure.atlassian.net/projects/ASYNC/issues/ASYNC-228. Would appreciate someone chiming in if they think this is major or not (while people are in here chatting)

noisesmith22:06:53

on the other hand there is take-while which stops after some condition is met, but I wouldn't recommend treating IO like channel ops as if they were lazy collections

colinkahn22:06:15

yeah I want to be able to create some go blocks but when I close the channels that they use all of those blocks are closed too (not sure the correct terminology for when a go block ends..)

colinkahn22:06:35

Thanks, this definitely makes it clearer