Fork me on GitHub
#core-async
<
2017-01-24
>
dalekbaldwin16:01:51

one of my coworkers has gotten it to run to completion by changing (>!! out x) to (go (>! out x)). so now I’m trying to figure out what’s the normal way to write pipeline functions. another example I found online used a go block enclosing both >! and close!, and the core.async library’s own tests use thread with blocking >!!. I have no idea how any of these variations are expected to behave within whatever mysterious context pipeline-async is orchestrating...

tbaldridge16:01:03

@dalekbaldwin yes, in the context of pipeline-async it expects the function to be "async" meaning, hand off the channel it gives you to some other thread and let that thread do the processing

tbaldridge16:01:23

So something like

tbaldridge16:01:30

(pipeline-async 2 to
   (fn [x out]
      (http/request x (fn [result]
                                             (put! out result)
                                             (close! out))))
   from)

tbaldridge16:01:43

wow, thanks slack for the horrific formatting

dalekbaldwin16:01:15

oh wow, there’s another aspect I didn’t even notice before. in the code I inherited and in this example I found: https://gist.github.com/JacobNinja/5c98496a632e1a466cbf#file-pipeline-clj-L7-L17 the handler puts on the same channel that is passed to pipeline-async, then closes the channel that was passed to it directly. in the code you just posted and in the official tests, it puts to and closes the channel that was passed to it directly.

tbaldridge17:01:40

not sure I understand what you're saying.

dalekbaldwin17:01:46

pipeline-async is passed out, and the the handler is passed out*; the handler puts a value on out and then closes out*. but from what I’m seeing now, it looks like you’re just supposed to put values on out* and then pipeline-async takes care of redirecting them all to out.

tbaldridge17:01:23

oh yes, absolutely, you should be putting data on the channel handed to you by the pipeline