Thanks for the rapid response! You could say that you put this in there as an exercise for the viewer; I know that in discussing it amongst ourselves, we definitely sharpened our understanding of some of the concepts.
I had tried submitting an erratum via O’Reilly before posting to this list, but for some reason that feature is not turned on for this video series. It is for others, so hopefully they can enable it for you as well. Cheers, -James On Thursday, September 17, 2015 at 3:54:54 PM UTC-5, tbc++ wrote: > > 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 <brun...@gmail.com > <javascript:>> 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 clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> 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.
