On 15/01/13 13:49, Marko Topolnik wrote:
It's not about futures, but about the way the ExecutorService is
configured. Clojure's /future-call/ apparently uses the /agent
send-off pool/, which is an unbounded thread pool executor. So you can
use the same thing with /Executors/newCachedThreadPool/ or instantiate
one directly with a constructor, which gives finer-grained control
over the behavior.
That's more like it!!! /Executors/newCachedThreadPool/ works exactly as
I 'd want without the risk of overwhelming the system with threads
(which the fixed-size pool will if I initialize it with (count coll))...
I have used this thread pool before - I can't believe my mind completely
forgot it! I think this is the best version of pool-map so far:
(defn pool-map
"A saner, more disciplined version of pmap.
Submits jobs eagerly but polls for results lazily.
Don't use if original ordering of 'coll' matters."
[f coll]
(let [exec (Executors/newCachedThreadPool)
pool (ExecutorCompletionService. exec)
futures (doall (for [x coll] (.submit pool #(f x))))]
(try
(for [_ futures] (.. pool take get))
(finally (.shutdown exec)))))
1. it keeps its semi-lazy nature which is good from memory-allocation
standpoint
2. will not block small tasks from finishing first (that is the whole
purpose of this pool)
3. completion service does what its supposed to do
4. the system will recycle threads accordingly
I'm feeling a lot more confident now... :)
Thanks a million Marko!
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
