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.

On Monday, January 14, 2013 11:15:10 PM UTC+1, 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?
>
>
> 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

Reply via email to