Fork me on GitHub
#core-async
<
2015-10-29
>
shaunxcode02:10:53

super happy about reduce respecting reduced - however I think the doc string should be more clear. Right now it ends with "ch must close before reduce produces a result." Which does not mention that it can also return a result before ch closing via reduced.

alexmiller02:10:28

when a channel transducer produces a reduced value, the channel will be closed

alexmiller02:10:22

not necessarily arguing that the docstring is clear enough, just not sure that you were aware of that

domkm06:10:58

@alexmiller: Would Cognitect consider unifying the core.async namespaces? Using it in a cljc file is quite cumbersome (clojure.core.async, cljs.core.async, and cljs.core.async.macros).

alexmiller12:10:00

Possibly, I need to talk about it with David and Rich

domkm15:10:04

Good to hear simple_smile

shaunxcode18:10:28

@alexmiller yeah I get that - what I am saying is that you can do like (def result-ch (ca/reduce (fn [x msg] (if (= msg :done) (reduced x) (conj x msg))) [] some-ch)) (ca/put! some-ch :a) (ca/put! some-ch :done) and some-ch will still be open, and result-ch will contain [:a]. The docstring makes it sound as if result-ch will not contain a result until the ch you pass in is closed. (at least that is how I read it)

alexmiller18:10:18

In this, case, the final put! will both deliver the result to result-ch AND close some-ch. The close will most likely happen in the thread of the put! while the delivery will happen asynchronously in a thread from the pool, so it's actually undefined which happens first. I think it would be clearer though if the docstring explicitly mentioned reduced, I'll ask Rich about it.

chrisn19:10:42

I have been studying the pub/sub interface from core.async and I have an issue I have been struggling with I would like to have some discussion over.

chrisn19:10:24

If I want to close a topic as the publisher it appears I have no way to close the channels that are subscribed to that topic.

chrisn19:10:56

If I am a client I can close my channel, no problem.

chrisn19:10:08

But from the other direction I only have the option of closing down the entire system by closing the publication channel. I have no way of closing just a particular topic down such that the clients of that topic will have their channels closed. This means that if a client does a go-loop in the normal way which simply doesn't recur if the channel is closed those go loops will now be orphaned.

snowell19:10:11

Can you not have the publisher send a poison pill sort of message?

snowell19:10:38

Subscriber receives it, exits the go-loop

chrisn19:10:16

I can work around this any number of ways and a poison pill would work. I could wrap the client channel with an intermediary that listens for nil or the poison pill and closes its wrapped channel. The external interface wouldn't change at all. So it is certainly a problem you can work around. It is just sort of an odd design given that closing channels and closing a topic seem to be analogous.

chrisn19:10:30

A boolean passed into unsub-all seems to me to be a bit clearer.

shaunxcode20:10:24

@alexmiller: to be as clear as I can here is a gist demonstrating that the ch you are reducing on is not explicitly closed by calling reduced from within the fn https://gist.github.com/shaunxcode/4f49eb4184fffc250742 (I am not saying this is right or wrong, just wondering if doc string is correct and behavior is wrong or vice versa - personally I think it is operating correctly as is and I can see use cases for wanting such behavior)

alexmiller20:10:38

ah, I've totally been thinking about channel transducers not a/reduce this whole time

alexmiller20:10:01

sorry, brain malfunction

alexmiller20:10:08

if you want to file a ticket for this, I'll get to it eventually