On Wed, 2009-06-10 at 22:23 -0700, Robert Lehr wrote: > Given that this will only occur w/ the send-off function, we can guess > that the tasks may on-average longer than functions that could be sent > via "send". that is b/c send-off is recommended for functions that > could block. That could be a thread or I/O or a lock, etc. > > Also, I didn't see a recommendation in the docs (or anywhere else) > that agent callbacks be short-lived tasks. In fact, some of the > things that I have been pondering would not be short-lived.
Well, in general thread pools don't go very well together with long running tasks. A fixed size thread pool could stop responding once all threads are blocked on I/O operations etc. Hence the cached thread pool which expands/contracts as needed. send-off uses the cached thread pool to stay responsive even if some individual threads block, but this does not mean that we should have lots and lots of long running threads in that pool. A brief notice can be found here: http://java.sun.com/javase/6/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool() The highly recommended "Java Concurrency in Practice" from Brian Goetz also talks about this topic. > Yeah...I saw that. Except that the code assumes that the agent will > be modified by only the agent's callback mechanism. I think we all > will recognize that that is not the strongest protection. It is > perhaps satisfactory b/c it is idiomatic Clojure to modify an agent's > state ONLY via the callback. > > So - is that correct? That agents are protected by serializing the > mutator functions invoked via "send" and "send-off"? You have to differentiate between API and implementation. The agent API consists of a bunch of functions which allow agent creation, action dispatching (send, send-off) and some more functions related to validation, dereferencing etc. You will notice that none of these functions change the agent state, instead the result of an agent's action (a function of the current agent state plus maybe additional arguments) will become the next agent state. So this is not an assumption, it is a guarantee of the API. Now w.r.t the implementation you can easily verify that the agent's state is only changed by an executing Action (here I am referring to the Action class). If you would mess around with the implementation, e.g. creating another class in the clojure.lang package which invokes setState on an Agent you are on your own of course (and then we wouldn't talk about Clojure anymore). What you get when you download clojure_1.0.0.zip is safe both in terms of API and implementation, and yes, this safety is achieved by serializing the state changes of an Agent. Cheers, Toralf --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
