Let it crash philosophy for distributed systems

This past weekend I read Joe Armstrong's paper on the history of Erlang. Now, HOPL papers in general is like Candy for me, and this one does not disappoint. There ' s more in this paper that I can cover in one post, so today I ' m going to concentrate on one particular feature of Er Lang highlighted by Armstrong.

Although Erlang is designed to encourage/facilitate a massively parallel programming style, it error handling may be even More noteworthy. Like everything else in Erlang, it error handling is designed to being distributed, and for good reason:

Error Handling in Erlang are very different from Error handling in conventional programming languages. The key observation here's to note that the error-handling mechanisms were designed for building fault-tolerant systems, And not merely for protecting from program exceptions. You cannot build a fault-tolerant system if you are only having one computer. The minimal configuration for a fault tolerant system have both computers. These must is configured so, both observe each other. If one of the computers crashes, then the other computer must take over whatever the first computer is doing.

This means, the model for error handling was based on the "idea of the" of "computers that observe".

Erlang is famous-it features which help programmers to produce stable systems in the real world. Its GKFX architecture and ability to Hot-swap code is well-known. But these features is available in other systems. The "Links" feature, on the other hand, seems to is unique. When you create a process in Erlang, you can link it to another process; This link essentially means, "If the process crashes, I ' d like to crash, also; And if I crash, that process should die, too. " Here is Armstrong ' s description:

Links in Erlang is provided to control error propagation paths for errors between processes. An Erlang process would die if it evaluates illegal code, so, for example, if a process tries to divide by zero it would die . The basic model of the error handling is to assume this some other process in the system would observe the death of the process and take appropriate corrective actions. But which process in the system should does this? If there is several thousand processes in the system then how does we know which process to inform when an error occurs? The answer is the linked process. If Some process A evaluates the primitive link (B) then it becomes linked to a. If A dies then B is informed. If B dies then A is informed.

Using links, we can create sets of processes that is linked together. If these is normal processes, they would die immediately if they is linked to a process this dies with an error. The idea here was to create sets of processes such that if any process in the set dies and then they would all die. This mechanism provides the invariant, either all the processes in the set is alive or none of them are. This is very useful for programming error-recovery strategies in complex situations. As far as I know, no other programming language have anything remotely like this.

In addition to simply killing the linked process, the link can also function as a kind of signal to a system process that A group of processes has died, so-appropriate action can be taken, such as restarting a process group.

Like Armstrong, I cannot think of the another system that works quite the this. The closest analogy I can think of is a distributed transaction. But distributed transactions has quite a bit more overhead, because they ' re all about providing serializable access to SH Ared data, which Erlang just doesn ' t allow.

Armstrong says that is inspired by the "C wire" in early telephone exchanges:

The C wire went back to the exchange and through all the electromechanical relays involved on setting up a call. If anything went wrong, or if either partner terminated the call and then the C wire is grounded. Grounding the C wire caused a knock-on effect in the exchange that freed all resources connected to the C line.

Armstrong says that the Links feature encourages a worker/supervisor style of programming which was "not possible in a sing Le threaded language. "

Let it crash philosophy for distributed systems