I have a complex dependency graph between the used agents, so it is difficult to compute the p-agent I want. (They are actually launched by watchers on the agents itself.)
After thought, agents may not be what I need. I may try to use Fork/Join instead... (What I do is a bit more structured on the computation graph, as opposed to asynchronous state. Maybe, I was a bit cheating by trying to use agents...) Has anyone contributed a wrapper for Fork/Join? Nicolas. On Fri, Dec 17, 2010 at 1:14 PM, Laurent PETIT <laurent.pe...@gmail.com> wrote: > 2010/12/17 nicolas.o...@gmail.com <nicolas.o...@gmail.com> >> >> I could, but I would have to add a watcher on every agent putting them >> into a seq hold by an atom. >> Which does not seem right, in some way... > > Is the thread which creates the agent calls the thread which will wait for > the agents being up to date at the end of the agents sends ? > > Why do you speak about holding the seq in an atom ? There are certainly more > than one way to skin your cat, some of them being more functional than that > ? > > For example using reduce: > > ; pseudo code with reduce > (let [used-p-agents (reduce (fn [p-agents a] (if (some-pred ...) (conj > p-agents (send a ....)) p-agents)) [ ] N-agents)] > (apply await used-p-agents)) > > Or loop ... > > ? > > HTH, > > -- > Laurent > >> >> On Fri, Dec 17, 2010 at 12:01 PM, Laurent PETIT <laurent.pe...@gmail.com> >> wrote: >> > 2010/12/17 nicolas.o...@gmail.com <nicolas.o...@gmail.com> >> >> >> >> Dear all, >> >> >> >> >> >> Is there a way to wait for all agents to be up-to-date without using >> >> await ? >> >> >> >> I am in a specific case with a lot of agents and I want all of them to >> >> have finished their work, >> >> and only a few of them had initially work to do. >> >> It is quite wasteful to explicitly await for N agents when only p << N >> >> were working, and you know that the thread pool >> >> for agents is idle after the p have finished working. >> >> >> > >> > So you cannot just call await on the p agents ? >> > >> > -- >> > 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 >> >> >> >> -- >> Sent from an IBM Model M, 15 August 1989. >> >> -- >> 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 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
