Also, 'doall' is a bad idea if the number of threads is large :-). You might want more control over the threadpool at that point. Futures uses http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool()
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6417 clojure.lang.Agent/soloExecutor https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Agent.java#L53 Notice that IFn (any clojure function) implements callable/runnable: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L23 Which is what executors need. On Sat, Apr 12, 2014 at 11:19 AM, Gary Trakhman <gary.trakh...@gmail.com>wrote: > I'd recommend running a doall on concurrent-list in order to realize the > futures, if you simply deref as you are, then you're going to delay the > execution of futures down the line as the sequence is realized bit by bit > (except chunking helps you here by accident). You are effectively > preventing later parts from getting realized until the earlier futures > return. > > But of course, there's likely a better approach, we'd need to know what > you're trying to do to address it. > > My first thoughts: > reducers? > executors? > core.async? > > You're not actually using the value returned from the future here, so it's > really a mild abuse of future just to get at the underlying thread-pool and > binding-conveyance (if you need it). You could use a lower-level > abstraction like executors or other things to have more control. > > > On Sat, Apr 12, 2014 at 7:52 AM, Cecil Westerhof > <cldwester...@gmail.com>wrote: > >> I first had the following function: >> (defn check-concurrent2 [] >> (init "concurrent2") >> (let [c1 (future (do-sequential 1 check-until 4)) >> c2 (future (do-sequential 2 check-until 4)) >> c3 (future (do-sequential 3 check-until 4)) >> c4 (future (do-sequential 4 check-until 4))] >> @c1 @c2 @c3 @c4) >> (deinit @max-factor)) >> >> But I did not like it, because it is ‘difficult’ to change. So I changed >> it to: >> (defn check-concurrent3 [number] >> (init (format "concurrent3 with %d threads" number)) >> (let [concurrent-list (for [i (range 1 (+ number 1))] >> (future (do-sequential i check-until >> number)))] >> (doseq [this-thread concurrent-list] >> @this-thread)) >> (deinit @max-factor)) >> >> Is a little bit clearer and also allows me to do the following: >> (def threads '(4 6 8 10)) >> >> (doseq [number threads] >> (check-concurrent3 number)) >> >> Is this the right way to do things, or is there a better way? >> >> -- >> Cecil Westerhof >> >> -- >> 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 >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
