On Wed, Jun 10, 2009 at 5:14 AM, Robert Lehr<robert.l...@gmail.com> wrote:
> Q - What stops Clojure's agent send-off function from becoming a DOS
> ("denial of service") vulnerability in a server?As you noted, send-off uses a cached thread pool, so there is no protection from creating more threads than your system can handle. In general cached thread pools should be used only for short lived tasks. The DOS protection must come from somewhere else in your system. > Q - How exactly does an agent protect its "state" from concurrency > issues, particularly race conditions since I do not see any locking on > agents. What is executed in a threadpool is Actions and the Agent's state is changed only in the Action's doRun() method. Actions are queued in a IPersistentStack (per Agent) and are executed in a strictly serial fashion, i.e. once an action completes, it will invoke the next if any. The only thing to watch out for then is enqueueing new actions, and to be thread-safe the queue (which itself is immutable like all Clojure collections) is held in a AtomicReference. > Q - how exactly is an agent's state changed? Check the Action's doRun() method: ... Object newval = action.fn.applyTo(RT.cons(action.agent.state, action.args)); action.agent.setState(newval); ... As written above the serial execution of an Agent's actions makes this thread-safe. Hope this helps (apologies for any inaccuracies). 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 -~----------~----~----~----~------~----~------~--~---
