On Fri, Aug 29, 2014 at 7:40 PM, Steve Murphy m...@parsetree.com wrote:
However, Erlang does not avoid all problems associated with concurrent
execution. In particular, it provides for interactions and communication
patterns between processes that may be stuck in their execution until
some
In practice, Erlang apps are more than the base actor machinery and
messaging. Erlang has a notion of 'linked processes' where a fault in a
linked process is reliably propagated to all linking processes. On top of
this they build a rich set of fault tolerant behaviors in OTP, one of
which, the
Steve,
Like I suggested, look at the CZMQ zactor class and the several
examples of actor classes in that library. You'll find most if not all
the answers you're looking for. It turns out to be surprisingly simple
to do proper multithreading in C, all you need is ZeroMQ inproc:// and
some patterns
On Thu, Aug 28, 2014 at 08:58:49AM -0600, Steve Murphy wrote:
Pieter--
Last year, I read the book, Programming Erlang, by Joe Armstrong, and I was
fascinated by the ideology behind the general thread-per-object approach,
where
each object is managed by its own thread, via message passing.
Goswin--
Thank goodness. I'm not alone.
I did a little research, now better than never:
http://james-iry.blogspot.com/2009/04/erlang-style-actors-are-all-about_16.html
(Actor patterns are all about locking)
http://people.inf.ethz.ch/chmaria/Pubs/TFP-2011.pdf
(in this second one, they
You may enjoy the CZMQ zactor model, which is somewhat inspired by
Erlang's view of things.
On Thu, Aug 28, 2014 at 4:58 PM, Steve Murphy m...@parsetree.com wrote:
Pieter--
Last year, I read the book, Programming Erlang, by Joe Armstrong, and I was
fascinated by the ideology behind the
Murf,
It depends on how you phrase the problem -- If you only ever process
the messages you receive on a single thread and in order, you will
never deadlock because you don't have the necessary conditions to
deadlock, which are shared state and more than one thread
accessing/modifying it
FWIW, Erlang's gen_server behavior supports a call() form which takes a
timeout (by default infinity). If the call times out, the call fails with
an exception, unless you catch this (not the usual Erlang way) the process
initiating the call will terminate, propagating the failure to any other
Trevor,
True, if the actor model can cover all multithreaded situations, then
that's the way to go. The question then becomes, does the actor
model cover all multithreaded situations, and if apparently not, can
the situation be adapted to turn it back into an actor compatible
situation?
Been
