[zeromq-dev] Erlang style messaging

Thomas Rodgers rodgert at twrodgers.com
Sat Aug 30 15:21:46 CEST 2014

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 supervisor behavior, uses the process linking machinery to
recover from failure conditions by incrementally restarting parts of the
application.  I mentioned earlier, the gen_server behavior (which is the
typical starting point for an Erlang process module), allows call() to
timeout.  This typically would be used to abort a 'stuck' message
send/receive operation.

In correctly designed Erlang apps, this would failure would propagate up
the supervisor hierarchy, restarting parts of the application to recover
from the fault, by terminating (there's even an option called brutal_kill
for this) the child processes of the supervisor and restarting in a known
state.  This isolation is very fine grained, the whole Erlang node doesn't
not typically fail, though if it does, there is a separate 'heart' process
launched by the node at startup, that can run a recovery script and respawn
the Erlang node.

So, while yes, the base Erlang model does not strictly avoid deadlocks, the
OTP behaviors built on top of base Erlang provide proven machinery for
recovering from these kinds of problems when the do occur.

On Saturday, August 30, 2014, Pieter Hintjens <ph at imatix.com> wrote:

> On Fri, Aug 29, 2014 at 7:40 PM, Steve Murphy <murf at parsetree.com
> <javascript:;>> 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 conditions are met, hence allowing certain kinds of deadlocks in
> > programs.
> First off, there's a good Erlang users list where you can ask this
> kind of question and get a response from the right people.
> Second, this sounds like scaremongering. Someone is trying to sell a
> solution to a pseudo problem, so they're creating drama. "Oooh, things
> could possibly go wrong!" Yes, any concurrent architecture could,
> potentially, get deadlocks if you set things up just right. However in
> practice, that's not what we see. The Internet does not deadlock. We
> don't deadlock while processing email. Real life does not deadlock,
> and actors approach real life quite closely in many ways.
> Actors block in the sense that they wait for work. However they do not
> block waiting for access to data, while trying to work. This is a
> profound difference. When an actor has work to do, nothing should be
> able to stop it. Yes, you can create interdependencies that cause
> deadlocking, however this is a pathological case.
> Anyhow, I don't think this kind of philosophy has much use. Write
> code, try to solve useful problems, improve your code carefully and
> without haste. If you can show a problem of deadlocking in an actor
> model, that would be useful input. The philosophy of maybes is, in my
> view, pointless.
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org <javascript:;>
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140830/e23aac4c/attachment.html>

More information about the zeromq-dev mailing list