Yes, I'm pretty sure that was a quick-and-dirty example, and I probably should have clarified that in the course.
You are correct, there is a race condition between the go loops, and that one of them may close the output channel before the others have finished processing their results. Probably better to stick with async/pipeline with a map transducer. And yes, the 0 vs 1 thing is a typeo. I'll have to see if there is a way I can submit some errata to O’Reilly. Thanks for the report. Timothy Baldridge On Thu, Sep 17, 2015 at 2:40 PM, James Elliott <brunch...@gmail.com> wrote: > We’ve been watching Timothy Baldridge’s great O’Reilly video series on > core.async, but are perplexed by one of the examples. In lecture 14 on > tuning back-pressure, he introduces a function map-pipe for giving a > channel a pipeline of work to do, and then as the final step, adds the > ability to add a level of parallelism. (Later in the series we find out > that there are more sophisticated tools along these lines already built in > to core.async, but this example is still interesting.) > > I can’t figure out how one aspect of it works, however. Here is the simple > function: > > (defn map-pipe > ([in out f] > (map-pipe 0 in out f)) > ([p in out f] > (dotimes [_ p] > (go (loop [] > (when-some [v (<! in)] > (>! out (f v)) > (recur))) > (close! out))))) > > The idea being that you can supply a level of parallelism by passing in a > value for p which is greater than 1, and the dotimes will spin up that > many go blocks working on the channel in parallel. My concern was this: > Since the close! happens asynchronously on one of those parallel go > blocks, surely the first instance which finds that in has closed can call > (close! > out) while the other instances are still working on their last task. > Won’t they then be unable to write their results to the now-closed channel? > Or is there some subtlety that none of us could figure out which prevents > this from being an issue? > > In writing up this question, though, I noticed another issue. The > three-argument arity of map-pipe should surely call the four-argument > version with a p value of 1, not 0, or nothing will ever get processed, > right? In fact that is what he says while he is editing the code, but ends > up typing a zero rather than a one. So I am thinking this may have just > been a quick example that ended up slightly wrong; it is one of the few > cases in the video series where the code is not run as it is written, so it > might have just been missed. > > But I worry that it is our understanding that is incorrect, not the > example, so I would appreciate some independent confirmation or correction. > > Cheers, > -James > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
