[prev in list] [next in list] [prev in thread] [next in thread]
List: zeromq-dev
Subject: Re: [zeromq-dev] Erlang style messaging
From: Thomas Rodgers <rodgert () twrodgers ! com>
Date: 2014-08-30 13:21:46
Message-ID: CAAB_aXujg7q9DSN=Xx7wiNsxf6=Uak48jHMThHf5v09o10sNoQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@imatix.com> wrote:
> On Fri, Aug 29, 2014 at 7:40 PM, Steve Murphy <murf@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@lists.zeromq.org <javascript:;>
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
[Attachment #5 (text/html)]
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. <div> <br></div><div>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.<br> <br>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.</div><div><span></span><br> On Saturday, August 30, 2014, Pieter Hintjens \
<<a href="mailto:ph@imatix.com">ph@imatix.com</a>> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On Fri, Aug 29, 2014 at 7:40 PM, Steve Murphy <<a \
href="javascript:;" onclick="_e(event, 'cvml', \
'murf@parsetree.com')">murf@parsetree.com</a>> wrote:<br>
<br>
> However, Erlang does not avoid all problems associated with concurrent<br>
> execution. In particular, it provides for interactions and communication<br>
> patterns between processes that may be stuck in their execution until<br>
> some conditions are met, hence allowing certain kinds of deadlocks in<br>
> programs.<br>
<br>
First off, there's a good Erlang users list where you can ask this<br>
kind of question and get a response from the right people.<br>
<br>
Second, this sounds like scaremongering. Someone is trying to sell a<br>
solution to a pseudo problem, so they're creating drama. "Oooh, things<br>
could possibly go wrong!" Yes, any concurrent architecture could,<br>
potentially, get deadlocks if you set things up just right. However in<br>
practice, that's not what we see. The Internet does not deadlock. We<br>
don't deadlock while processing email. Real life does not deadlock,<br>
and actors approach real life quite closely in many ways.<br>
<br>
Actors block in the sense that they wait for work. However they do not<br>
block waiting for access to data, while trying to work. This is a<br>
profound difference. When an actor has work to do, nothing should be<br>
able to stop it. Yes, you can create interdependencies that cause<br>
deadlocking, however this is a pathological case.<br>
<br>
Anyhow, I don't think this kind of philosophy has much use. Write<br>
code, try to solve useful problems, improve your code carefully and<br>
without haste. If you can show a problem of deadlocking in an actor<br>
model, that would be useful input. The philosophy of maybes is, in my<br>
view, pointless.<br>
<br>
-Pieter<br>
_______________________________________________<br>
zeromq-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', \
'zeromq-dev@lists.zeromq.org')">zeromq-dev@lists.zeromq.org</a><br> <a \
href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" \
target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br> \
</blockquote></div>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic