Hi, disclaimer: I'm only a hobbyist with almost no clue about the concurrency. So take this with a grain of salt. The following are only my expressions how this stuff works.
Am 10.06.2009 um 05:14 schrieb Robert Lehr:
Q - What stops Clojure's agent send-off function from becoming a DOS
("denial of service") vulnerability in a server?
send-off spawns new threads as necessary, AFAIK. That means a sufficiently fast spawn process my get the machine in trouble. Use with care. send uses a thread pool, which means, that the sent action might be queued up until a free thread becomes available. I'm not sure that I/O should be done in agent actions. I see the action to move the agent's state to a new form. agents are not threads.
Q - How exactly does an agent protect its "state" from concurrency issues, particularly race conditions since I do not see any locking on agents.
The only way to change the state from within Clojure is to sent it an action. actions are queued so there is only one active action at a time for an agent. Other actions (possibly sent from different threads) wait in the queue. So there cannot be a race condition.
Q - how exactly is an agent's state changed? all of the agent docs and APIs (that I have read (a lot)) describe their asynchrony, albeit w/o much detail beyond the API itself. Some of those including in those descriptions changing the agent's state. are they updated like Refs? like an ordinary Var? they appear to be Refs. they act like Refs. but NO docs nor examples show agents being protected. So I am a bit confused about this, too.
The action is passed the current state of the agent, the new state is the return value of the action. The state is changed in the agent itself by whatever coordinates the action queue. No looks are whatever required... Sincerely Meikel
smime.p7s
Description: S/MIME cryptographic signature
