Fork me on GitHub
#docs
<
2017-09-22
>
bfabry18:09:34

anyone think the docstring for https://clojure.github.io/core.async/#clojure.core.async/pipeline-async is inconsistent with the behaviour of:

(async/pipeline-async 
  10
  (async/chan 100)
  #(async/thread  (async/>!! %2 %1) (println "put " %1 " once") (async/>!! %2 %1) (println "put " %1 " twice"))
  (async/to-chan (range 10)))

bfabry18:09:56

docstring specifically says "result(s)" but my reading of the code (and those results) is that af can only reliably place 1 result

Alex Miller (Clojure team)18:09:36

“af must close! the channel before returning”

Alex Miller (Clojure team)18:09:26

there is at least one pending ticket related to the docs for this

bfabry18:09:21

ah! ok apparently I just didn't understand the code when I read it

bfabry18:09:49

because you're right, if I close the channels it works as intended.

bfabry18:09:02

so it works, but it's not asynchronous anymore after the first value is put on the channel

bfabry18:09:39

(async/pipeline-async
  10
  (async/chan 100)
  #(async/thread
     (async/>!! %2 %1)
     (println "put " %1 " once")
     (Thread/sleep 1000)
     (async/>!! %2 %1)
     (println "put " %1 " twice")
     (Thread/sleep 1000)
     (async/>!! %2 %1)
     (println "put " %1 " thrice")
     (Thread/sleep 1000)
     (async/close! %2))
  (async/to-chan (range 10)))
=>
#object[clojure.core.async.impl.channels.ManyToManyChannel
        0x1be4a99a
        "[email protected]"]
put  put 0   once5
 put  4  once
put  1 once 
 once
put  2  once
put  put 6  9 once 
 once
put put  put 8  3  once 
 once
7  once
put  0  twice
put  0  thrice
put  1  twice
put  1  thrice
put  2  twice
put  2  thrice
put  3  twice
put  3  thrice
put  4  twice
put  4  thrice
put  5  twice
put  5  thrice
put  6  twice
put  6  thrice
put  7  twice
put  7  thrice
put  8  twice
put  8  thrice
put  9  twice
put  9  thrice

bfabry18:09:26

or.. it's "asynchronous" but the channels and threads block each other in such a way that things can only happen in sequence

bfabry18:09:09

I suppose that's probably necessary for "Outputs will be returned in order relative to the inputs." it's surprising though

Alex Miller (Clojure team)19:09:02

it’s necessary for ordering

bfabry19:09:02

indeed. I guess pipeline just isn't a great fit here