Do not block Agent#value when updating && other improvements

[pitr-ch]

see https://github.com/jdantonio/concurrent-ruby/blob/master/lib/concurrent/agent.rb#L163

I'll submit PR later. What is the schedule for 0.6 release? how much time do I have If I would like to get this fix in?

• do not block reading when updating
• does not allow to execute two updates at the same time

Other:

• add await as in Clojure
• creates another thread for each post call see https://github.com/jdantonio/concurrent-ruby/blob/master/lib/concurrent/agent.rb#L164
• do not send subsequent posts on failure, clojure agent doc: "If any exceptions are thrown by an action function, no nested dispatches will occur, and the exception will be cached in the Agent itself."
• support send and send-offfor blocking IO functions

[mighe]

Just for curiosity, could you provide an example/use case for this problem?
When I saw that method, I left the block call inside the mutex thinking that we are already passing the current value to the block, so there is no reason to call any other synchronized method of the object.
Clearly I was wrong 😊 and it should be fixed

No schedule for 0.6, so you can go and fix it.

[jdantonio]

I was supposed to create a pre-release build last Friday but I haven't yet. I had planned to create actor pools for that pre-release but I've been very busy lately and haven't had as much time for the gem as I would have liked.

@pitr-ch Please take whatever time you need to make the update. We greatly appreciate your help. Also, I was not aware of your Actress until just now but it looks like you and I share many of the same ideas about actors. Would you be interested in collaborating?

[jdantonio]

@pitr-ch I just took a look at your Algebrick library, too. I've also experimented with Erlang-inspired pattern matching in Ruby. You and I definitely share many of the same influences and ideas.

[pitr-ch]

@jdantonio Yep I would be interested in collaborating :) Thanks for the link I'll look at the functional-ruby. Converted this issue to PR. I've opened #66 to track the Actor pool-ification.

[pitr-ch]

@mighe use-case: I don't have a concrete one, but I would imagine that when an app would be using agents heavily, it would cause delays and even deadlocks (e.g. two agents reading each other). This is also one a fundamental features of clojure that the agent can be read at any time without coordination.

@jdantonio could you look at/restart travis please?
update: restarted by amend