On Jan 23, 10:43 pm, e <evier...@gmail.com> wrote:
> Just to understand ... 'send-future' works too but you don't think that's
> the way to go?
The Agent send pool has a limited size, so doing recursive calls with
a stack greater than that size will result in a freeze (waiting for
new threads that can't be made yet). So send-future can't be used with
my naive example only send-off-future. However being a naive example
it is also very inefficient, a real implementation would be more
careful in dividing up the work, and in doing so would remove this
recursive requirement. I was mainly exploring the differences between
futures and agents, and it seemed to me that futures were convenient
in cases like this (one shot computations).
> Also, I need to see if the Java code has a place for a user
> to specify the thread pool size. Otherwise is that best handled by
> send-off-future wrapping a generator that can throttle or something?
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executors.html
(.. Runtime getRuntime availableProcessors)
You could divide the input into nprocessors subsets and run them as
futures using a normal pquicksort, and combine the results and return
them. This is a similar strategy to pmap in core.clj, which uses
agents.
Regards,
Tim.
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
