On 14/01/13 22:15, Marko Topolnik wrote:
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?
I'm not entirely sure what you mean here...The only real reason I am using 'doall' is so that I can shutdown the ExecutorService, otherwise I wouldn't mind returning a lazy-seq. In fact that is how I originally had it - I was never shutting down the pool until recently! Inside the doall however I'm polling the pool for answers and *it* looks for finished jobs...I'm not deref-ing the futures in a serial manner which has higher chances of bocking...Is my thinking not correct?
Yet another issue with your function is that it doesn't submit all the tasks up front so it clearly won't prevent longer tasks from delaying the shorter ones. But, even if they are submitted all at once, like in my version, the executor service will still enqueue them internally, with the same end result. You'd need an unbounded thread pool, and that would obviously bring in other issues.
You're quite right here...Again using 'for' was a remnant from the old version...Perhaps 'mapv' would be a better choice for submitting the jobs...In any case, is this executor-based approach (with or without the completion service) encouraged? Would you care if tomorrow pmap started using this approach?
btw, thanks for your time and comments...very helpful! Jim -- 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
