[erlang-questions] Best practices for handling invalid / unexpected messages

[Ulf Wiger]

On 13 May 2011, at 22:24, Ciprian Dorin Craciun wrote:

>    My problem is monitoring vs linking. Linking seems more
> "bullet-proof" than "monitoring"…

No, monitors and links are just *different*, and complementary.

The great value of links - their intended use, original impetus and default mode - is cascading exits. If a process dies, all processes linked to it will also die. As Bjarne Däcker has told, this idea came from the old telephone switches where grounding the 'C' line would release all resources held by a call, through a cascade of relays.

There was another mode needed, where a process reached by an exit notification was not terminated, but instead could react. The initial solution was to modify the behaviour of EXIT signal reception through the process flag 'trap_exit'. But as is often the case when overloading a behaviour, the solution was flawed:

- you can call link(P) as many times as you want, but you will only have at most one link to process P
- if you call unlink(P) even once, the link to P will be removed
- this meant that link/1 was impractical for temporary supervision, a la gen_server:call/2

(A potential problem in the old days was that if a child unlinked from its supervisor, this could subvert the shutdown protocol and make shutdown hang. Nowadays, supervisors use both links and monitors…)

So monitors were included to make it possible to react instantly to the death of a process, if it happens to die *as I am interacting with it*, but ignore it otherwise. As it happens, monitors are also great for monitoring processes. Links remain great for their original purpose - cascading exits.

BR,
Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com