Hi Rich, Would you accept a patch to allow either pool to be selected? (you have my CA) http://groups.google.com/group/clojure/web/futures.patch (future (+ 1 2)) (future-pool (+ 1 2)) I think the naming is a bit tricky and might need adjusting (something that shadows send/send-off might be better).
Why would I want this? When I have lots of tasks to do but want to keep roughly to the CPU size number of threads. Regards, Tim. On Mar 2, 9:58 am, Rich Hickey <[email protected]> wrote: > On Mar 1, 2009, at 1:53 PM, Anand Patil wrote: > > > > > > > Hi all, > > > My concurrent dabblings in Clojure have been a real pleasure so far. > > In terms of concurrency, it's just in a completely different league > > from any other language I've tried. However, I think agents could be > > made even more friendly by allowing them to temporarily surrender > > their place in the thread pool pending another computation. > > > Specifically, I'm thinking of a function 'yield' called as (yield > > other-agent msg-fn args) from within agent actions. If agent a yields > > to agent b, a gets off the thread pool and msg is sent to b with given > > args. When b finishes executing the message, the yield call returns > > b's new value, and a gets back on the thread pool. > > > I _think_ the language could prevent deadlocks by: > > - making agents not take any messages while they are 'yielded' > > - keeping a 'yield stack' and checking that no cycles happen. > > > Here are two use cases for yield: > > > 1) Say an 'auto-agent' cell needs to run an expensive, parallelizable > > computation to update its value. Without yield you could do this by > > dispatching the action with send-off, or by splitting the cell up into > > multiple cells, each handling a chunk of the computation. Yield would > > be nicer than both: send-off spawns an expensive kernel thread (as I > > understand it) and breaking up the cell complicates the dataflow model > > unnecessarily. > > > 2) Currently this program, which creates a tree of dependent futures, > > deadlocks on my 8-core mac pro: > > > (def breadth 4) > > > (defn with-deref [fun] > > (fn [& x] (apply fun (map deref x)))) > > > (defn future-tree [depth] > > (if (= depth 0) (future 1) > > (let [new-futures (map future-tree (repeat breadth (- depth > > 1)))] > > (future (apply (with-deref +) new-futures))))) > > > ; WARNING: This deadlocks on 8-core Mac Pro! > > (future-tree 4) > > > I'm guessing it deadlocks because the thread pool fills up with > > futures that aren't ready to go, but it feels like the language should > > be able to avoid the deadlock without requiring the programmer to > > think about how many threads are actually in the thread pool. If > > futures were based on agents, which yielded when deref-ing other > > futures, the deadlock wouldn't happen. > > > I have no idea how hard it would be to implement yield, as I have very > > little practice with Java. Thoughts? > > I've made futures use the Agents' CachedThreadPool, which should > prevent the thread pool exhaustion (svn 1316). You shouldn't worry > about the expense of the threads, that's why there's a pool. > > Yield as you've described it is definitely not going to happen. > > Rich --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
