Thanks.  See reponses inline.

On Jun 10, 6:22 am, Toralf Wittner <toralf.witt...@gmail.com> wrote:
> On Wed, Jun 10, 2009 at 5:14 AM, Robert Lehr<robert.l...@gmail.com> wrote:
e in your system.
>
> > 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

OK - that's one person that agrees w/ me.

> In general cached thread pools should be used only for short lived tasks.
> The DOS protection must come from somewhere else in your system.

Right - as long as it *IS* solved elsewhere in the system.  The
potential has to be recognized first which is impossible unless it is
documented or one reads the source code.

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.

> > 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.
>

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"?

-robert

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to