Thanks, Daniel.
See responses inline.
On Jun 10, 2:10 am, Daniel Lyons <fus...@storytotell.org> wrote:
> Robert,
>
> You have some interesting questions. I'm going to share my impressions
> of the answers based on reading the website and the book. I am rather
> new to Clojure myself and I haven't read the source code to it so
> perhaps any mistakes I make are representative of newbie pitfalls in
> general or possibly even oversights in the documentation. Perhaps some
> of those more in-the-know can illuminate us both.
>
> On Jun 9, 2009, at 9:14 PM, Robert Lehr wrote:
>
> > Q - What stops Clojure's agent send-off function from becoming a DOS
> > ("denial of service") vulnerability in a server?
>
> Well, the way I see it, there are two possibilities:
>
> 1. Threads are so cheap, we can have as many as we want and it isn't a
> problem (the Erlang solution)
> 2. Threads are expensive, so they are pooled and can be maxed out.
>
Right-o except that a computer is a machine w/ finite capacity. One
might say "miniscule" compared to the capacity that is available via
the Internet. IOW, if a socket-server is going to rely on thread-pre-
request model can be exhausted by a DDOS attack.
>
> I suspect there is a pool because pmap manages a pool internally and I
> don't understand why you'd call an object a CachedThreadPool if it
> just spawned new threads without any regard.
Neither do I. But I do not associate much significance w/ names
anymore. As RH said in one of his Clojure videos, although a
namespace is infinite, the usable namespace is not.
Regardless, I am working from the docs that I cited. So whatever our
interpretation of the names, the docs describe that particular thread-
pool class as being unbounded (barring the a system's limits/
capacity).
> If it is a size-
> constrained pool, this is what's keeping send-off from being a
> vulnerability. Of course, if you're being DOS'd, pretty much every
> function which costs anything is a vulnerability, isn't it? :)
>
yep. but some things cost more than others. admittedly, i do not
know the cost of a thread. but i am pretty sure that a context-switch
is much less expensive than iteration through a "container" of
objects.
>
> > Q - How exactly does an agent protect its "state" from concurrency
> > issues, particularly race conditions since I do not see any locking on
> > agents.
>
> Based on my understanding of how transactions work, refs are protected
> using MVCC or something like it. My source is the page on refs:
>
And THAT is precisely the point of my question - I do not see any
reference (ignore the pun) to ANY kind of concurrency-protection of
the agent, in the docs, examples, API nor source. That includes the
STM/MVCC functionality that RH implemented in Clojure via Refs and
Atoms.
Given the importance of this issue, I can assume that the protection
is implicit in the agent functionality unless it is explicitly
documented somehwere, especially in the source.
Again - perhaps I am just not seeing it.
>
> > Q - how exactly is an agent's state changed?
>
> My impression is that it works like a ref that belongs to another
> thread.
>
Agreed. That SEEMS to be implied. However, an implied guaranteed is
insufficient. W/o an explicit statement that says as much, either in
docs, API or source, I cannot accept that this is true.
>
> On Jun 9, 2009, at 8:32 PM, Robert Lehr wrote:
>
> > My primary concern is that for certain kinds of transactions, use of
> > 'commute' creates a race condition between transactions that operate
> > on a common set (non-null) of Refs.
>
> I'm pretty sure MVCC takes care of this problem in general. However,
> in theory (I don't know about Clojure specifically) there are still
> situations in which deadlock can occur.
I am pretty sure that Clojure won't deadlock since it doesn't use
locks.
The problem is that I do not see STM/MVCC being used anywhere to
protect the agent from the race-condition. I suspect that it may be
there ~somewhere~. Hence my inquiry. And if it not there
then...that's a problem. :)
One might accept as evidence that an exception is not thrown when the
agent is modified by the agent's update-fn. W/ that in mind, I am
inclined to believe that the agent is being protected somewhere,
somehow. But, as I have stated at other times, for something as
crucial as concurrency, empirical evidence is insufficient.
-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
-~----------~----~----~----~------~----~------~--~---
