Imho, using agents(or fixed size thread pool) in my case could be worst than using an unbounded thread pool. There's a risk to have all agents blocked waiting for each other. The library "die-geister" seems to perfectly fit my needs. Great! Still I would be grateful to hear a solution using only the clojure/ clojure-contrib api.
On 11 sep, 10:29, Laurent PETIT <laurent.pe...@gmail.com> wrote: > Hi, > > now that I've stepped back a little bit and acknowledged my ignorance (while > working on it : currently reading "Java concurrency in practice" :-) ), I > can see why I've been so prompt to suggest that (while I can remember having > said to others that using agents without caring about their state seems like > an abuse) : futures and agents are part of core clojure. And unless I've > overlooked clojure's core, one must go fall back to java interop if one > wants its own thread pool. > > This remains me of the "viscosity" smell : if it's way easier to do the > wrong thing than it is to do the right thing, expect people to do the wrong > one. > > Thanks for pointing me to "smack of" definition. This way I've learned two > things at once ;-) > > Cheers, > > -- > Laurent > > 2011/9/11 Kevin Downey <redc...@gmail.com> > > > > > > > > > what you were suggesting, if I understand correctly, is > > re-implementing futures using agents instead of a thread pool. > > > send an action off to an agent to be run, return a promise, the action > > delivers to the promise when the action completes. derefing the > > promise blocks until the action is run to completion. > > > submit a Runnable/Callable to an executor, receive a Future. calls to > > get on the future block until the Runnable/Callable runs to > > completion. > > >http://www.phrases.net/phrase/6934 > > > "Using agents when you want a thread pool gives the impression of > > ignorance." > > > On Sun, Sep 11, 2011 at 12:24 AM, Laurent PETIT <laurent.pe...@gmail.com> > > wrote: > > > 2011/9/11 Kevin Downey <redc...@gmail.com> > > > >> I hate to see agents used this way. If people want a thread pool they > > >> should either use the ones provided by clojure, or create their own. > > > > That's right, the "agents" part of my answer is more a hack. > > > But the more interesting point I wanted to bring to the table for the > > > brainstorming was the use of dataflow variables (via promise/deliver). > > I'd > > > be happy to have your thoughts on this, provided that you're able to > > choose > > > more delicate words/judgements than "smacks of ignorance", which, even if > > > there's a possibility that as a non native english speaker I'm > > interpreting > > > the wrong way, seem rude and hard to swallow. > > > >> Using agents when you want a thread pool smacks of ignorance. > > >http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Thr... > > > >> You can tell when you should be using a threadpool/futures instead > > >> agents when you don't use an agent as an identity over a series of > > >> values. > > > >> On Sat, Sep 10, 2011 at 11:14 PM, Laurent PETIT < > > laurent.pe...@gmail.com> > > >> wrote: > > >> > Hello, > > >> > Would it make sense to use instead promise/deliver, and enque > > >> > computations > > >> > in order in agents queues ? (worse parallelism, but more control over > > >> > the > > >> > number of threads ?) > > > >> > 2011/9/10 Illim <illminou...@gmail.com> > > > >> >> I'm a clojure beginner and from the future api , the only way I found > > >> >> to create a future from another is to block the resulting future's > > >> >> thread with 'deref'. I'm a little bit afraid of exhausting my thread > > >> >> pool. > > >> >> For example: > > >> >> (def x (future 1)) > > >> >> (def y (future (+ 1 @x))) > > >> >> y will block and consume a thread during x computation. > > > >> >> -- > > >> >> 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 > > > >> -- > > >> And what is good, Phaedrus, > > >> And what is not good— > > >> Need we ask anyone to tell us these things? > > > >> -- > > >> 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 > > > -- > > And what is good, Phaedrus, > > And what is not good— > > Need we ask anyone to tell us these things? > > > -- > > 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