Fork me on GitHub
#core-async
<
2018-02-14
>
pyr10:02:36

@noisesmith I'm still unsure about the validity of my approach, waiting on feedback

alexmiller14:02:55

hey @pyr, I answered your mailing list post there but I do hope to look at some async stuff in the near future (but it still might be a few weeks before I get there)

pyr15:02:03

Hi @alexmiller, thanks so much

pyr15:02:36

I hope I have added enough information to give you good situational awareness

tbaldridge15:02:21

@pyr If I'm understand the problem I think this is by design. Closing a channel results in a logical termination value being put into the channel.

tbaldridge15:02:36

This is so that, by default, core.async won't loose data.

tbaldridge15:02:21

Most of the time when I encounter this problem I fix it by draining the channel:

(defn drain [c]
  (go (while (not (nil? (<! c)))
          nil)))

tbaldridge15:02:37

And then:

(close! c)
(drain c)

pyr16:02:26

let me test my use-case with drain

pyr16:02:46

I suspected this might be the case

pyr16:02:40

@tbaldridge so If I read you right, a put! having its callback never called, or a >!! blocking forever if a close! occurs but no drain is expected

pyr16:02:00

Ah indeed

pyr16:02:05

because even after closing

pyr16:02:09

takes can happen

tbaldridge16:02:14

Right, the way to think of it is a close! acts like a termination message that gets enqueued into the channel. Thus the channel won't be completely closed until that message is processed. Internally it doesn't work that way at all, but it's a good mental picture that works.

pyr16:02:16

which would drain the buffer

pyr16:02:33

yes, I'm more familiar with the internals now 🙂

pyr16:02:00

at least this rabbit-hole helped with getting more visibility into them

tbaldridge16:02:14

Yes, it's annoying, but I've run into several cases where if it didn't work this way, you'd have some nasty race-conditions and data loss.

pyr20:02:22

Thanks for the explanation, I'll amend the issue.