> *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))...
>
You will either ovewhelm the system with threads or have the tasks waiting
in the queue, there
> (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
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/
> so Java Futures are not the same as Clojure futures then! A
> Clojure future will fire up as soon as you define it yes? If what you
> say is true, then Java Future objects are not the same! I was under the
> impression that as soon as you submit the job and get the Future Object
> back , th
On 15/01/13 12:57, Marko Topolnik wrote:
The tasks are waiting in the queue, they are not being executed at
all. And the time they spend waiting cannot theoretically be a
function of the time they will take to execute, once they get their
chance.
a so Java Futures are not the same as Cloj
user=> (def dummy-times [3000 10 9 8 7 6 5 4 3 2 1])
> #'user/dummy-times
> user=> (time (pmap #(do (Thread/sleep %) %) dummy-times))
> "Elapsed time: 16.213366 msecs"
> (3000 10 9 8 7 6 5 4 3 2 1);;here you waited 3s before sleeping for
> 0.01 s
> user=> (time (pool-map #(do (Thread/sleep
On 15/01/13 09:25, Marko Topolnik wrote:
The order in which you are polling is not very relevant given the fact
that /doall/ won't return until *all* futures are realized. It's just
an internal detail.
I finally fully grasped what you were saying...So yes you're right - as
long as I'm forcing
On Tuesday, January 15, 2013 12:36:04 AM UTC+1, Jim foo.bar wrote:
> 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 d
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 on
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
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
On 14/01/13 21:27, Jim - FooBar(); wrote:
On 14/01/13 20:47, Marko Topolnik wrote:
What exactly is the value provided by ExecutorCompletionService? To
my eyes, this function is quite similar to (comp doall pmap), but
with shuffled result. There is no advantage to using the lazy
approach to sub
On 14/01/13 20:47, Marko Topolnik wrote:
What exactly is the value provided by ExecutorCompletionService? To my
eyes, this function is quite similar to (comp doall pmap), but with
shuffled result. There is no advantage to using the lazy approach to
submitting tasks: you could have simply used i
> (defn pool-map
> "A saner, more disciplined version of pmap. Not lazy at all.
> Don't use if original ordering of 'coll' matters!"
> [f coll]
> (let [cpus (.. Runtime getRuntime availableProcessors)
>exec (Executors/newFixedThreadPool cpus)
>pool (ExecutorCompletionService.
14 matches
Mail list logo