On Aug 4, 2010, at 3:00 PM, Matt Fowles wrote:
> 
> Doug Lea (of java.util.Concurrent fame) designed a framework called Fork/Join 
> which is made to separate the idea of work from threads so that things can be 
> parallelized out as much as possible.  I don't know clojure that well, but 
> would guess that it has some support for it and that you would see the best 
> parallel fan out if you use the framework instead of explicitly managing your 
> thread counts like this.

Hmm -- apparently there's some Fork/Join support but it is deprecated 
(http://clojure.org/other_libraries).

FWIW I'm not explicitly managing thread counts in any of my code -- I'm letting 
pmap do it or whatever is behind the management of "send"s to agents or the 
forcing of futures. I added Armando's suggest "burn-via-pool" test, which does 
explicitly manage threads, just to see what that would do, but one of the 
appeals of Clojure's concurrency support is that I shouldn't (I hope!) have to 
think about this...

 -Lee

--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspec...@hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438

Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/

-- 
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