But... you were quite clear in stating that your function isn't lazy, and you were right to say that: *doall* will not return until *all* the tasks have completed. Maybe you did want laziness, after all?
On Monday, January 14, 2013 10:27:18 PM UTC+1, Jim foo.bar wrote: > > I think the advantage of ExecutorCompletionService is that , it will > give you back any of the futures that finished , not necessarily the > first but that which finished first (this is why you lose ordering as > well). It is certainly idiomatic, at least in Java, to do that...When > you submit to the completion service , it submits to the executor-pool > it is wrapping...I think your version will behave as pmap, meaning that > realising the result of '(map #(.get %) r)' will potentially block if > the 1st item (or the first items in general) takes ages to finish and > that is one of the problems with pmap. It won't move on to the 2nd chunk > unless all tasks from the 1st chunk have completed. This is why pmap > will not work well when you have irregularly sized data leading to > irregularly sized execution times per task...I 've been bitten before by > this and this is why I am using pool-map instead...The completion > service will return whatever future has completed (if any) which gives > more time to the longer tasks to comlete... I don't have any links to > share at the moment but several hours of googling has led me to > this...some of the best Java code that I saw uses this as well (when the > ordering doesn't matter). > > > > -- 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
