<div dir="ltr">Fred Hebert's blog - It's about the guarantees - has a good discussion regarding why it's not always about "restart & pray"<br><div class="gmail_extra"><br></div><div class="gmail_extra">
<a href="http://ferd.ca/it-s-about-the-guarantees.html">http://ferd.ca/it-s-about-the-guarantees.html</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br>Rich<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Message: 20<br>
Date: Thu, 26 Jun 2014 21:40:31 +0200<br>
From: Lo?c Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>><br>
To: Raoul Duke <<a href="mailto:raould@gmail.com">raould@gmail.com</a>>,  erlang-questions<br>
        <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>
Subject: Re: [erlang-questions] obviously no bugs? (Re: Alternative<br>
        supervision approaches)<br>
Message-ID: <<a href="mailto:53AC772F.9000403@ninenines.eu">53AC772F.9000403@ninenines.eu</a>><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
On 06/26/2014 09:10 PM, Raoul Duke wrote:<br>
>> I was referring to something formally based on an FSM and detecting the<br>
>> current<br>
>> environment and state of the node before restarting the children and not<br>
>> just using<br>
>> timeouts. Not sure if that was clear based on your response.<br>
><br>
> whatever the mechanism, the point to me is that i get the impression that:<br>
><br>
> a) it failed at all in the first place and b) it seems like it is not<br>
> always an expected failure and c) the "fix" is to restart & pray and<br>
> then if the prayers don't work then wait a little longer or do some<br>
> as-yet-unspecified random jiggery-pokery of the 'environment' and<br>
> start praying again.<br>
<br>
a) Even statically checked things fail. The program may run out of<br>
memory. The network might go down. Network might be slow or bumpy.<br>
Hardware may fail. Knowing that your program works on paper is nice, but<br>
has its limits.<br>
<br>
b) An infinite number of things may fail. The only thing you can expect<br>
is that something *will* fail. You can't prevent that. You can only make<br>
sure that when something does fail, you recover as gracefully as possible.<br>
<br>
c) I'm not sure where you got the "wait a little longer" part, because<br>
neither Erlang nor OTP waits. The point is to restart processes in a<br>
consistent state, and then if we can't do that (for example we depend on<br>
an ets table managed above in the tree), restart a larger group of<br>
processes. The VM crashing is when something *really bad* happened and<br>
you typically want a dirty human to look at it, but many odd failures<br>
aren't worth spending much time over.<br>
<br>
> i just wonder how many other people have similar pie-in-the-sky<br>
> day-dream wishes or if the standard groupthink is, "eh, whatever,<br>
> restarts will be enough to get us shipping and maybe making a profit!"<br>
<br>
It's about solving a real world problem, which is that programs fail.<br>
<br>
> on the other flipper, if one were programming with CSP or some such<br>
> then in theory you'd "simply" run FDR over your code and get answers<br>
> about deadlock for "free". vs. doing something in TLA and then<br>
> maintaing it vs. the "real" code.<br>
<br>
Dialyzer has some race condition checks nowadays. Concuerror can help<br>
you find many race conditions and deadlocks too.<br>
<br>
But neither of those can anticipate all possible cases that make program<br>
fail. They are very nice to have because they allow you to increase the<br>
quality of your codebase, but they do not solve the problem of programs<br>
failing.<br>
<br>
You can think of and test for many failure cases but you can never cover<br>
them all. You still need supervision and restarts regardless of how well<br>
your codebase is tested.<br>
<br>
Stop dreaming and start building real things, I say.<br>
<br>
--<br>
Lo?c Hoguin<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
<br>
<br><br>
</blockquote></div><br></div></div>