concept supervisor in category erlang

This is an excerpt from Manning's book Erlang and OTP in Action. Login to get full access to this book.

Such a signal-trapping process is sometimes called a system process and typically runs code that is different from that run by ordinary worker processes, which don’t usually trap signals. Because a system process acts as a bulwark that prevents exit signals from propagating further, it insulates the processes it’s linked to from each other and can also be entrusted with reporting failures and even restarting the failed subsystems, as illustrated in figure 1.3. We call such processes supervisors.

Figure 1.3. Supervisor, workers, and signals: the crash in one of the worker processes is propagated to the other linked processes until the signal reaches the supervisor, which restarts the group. The other group of processes under the same supervisor isn’t affected.

Supervisors are one of the most important features of OTP. They monitor other processes and take action if anything goes wrong, restarting the failed process or possibly escalating the problem to a higher level. Layering supervisors into supervision trees allows you to create highly fault-tolerant systems.

In this chapter, we don’t go too deeply into the theory and practice of applications and supervisors. We mostly concentrate on how to armor the module you created in chapter 3, wrapping it up as an OTP application and setting up a supervisor for it. We go over the most basic aspects of these tasks and explain what you’re doing at each step. Later, in part 2 of this book, we go into more detail and talk about all the interesting options that are available for advanced supervision, for handling code within applications, and even for packaging multiple applications into a larger structure called a release.

4.2. Adding fault tolerance with supervisors

Supervisors are one of the core things that make Erlang/OTP what it is. An active OTP application consists of one or more processes that do the work. Those processes are started indirectly by supervisors, which are responsible for supervising them and restarting them if necessary. A running application is essentially a tree of processes, both supervisors and workers, where the root of the tree is the root supervisor. Figure 4.2 illustrates a possible process structure for a hypothetical application.

Figure 4.2. Process tree for a hypothetical application. This example has a root supervisor with one immediate worker process and one subsystem supervisor, the latter with two workers.

You create supervisors by writing modules that implement the supervisor behaviour. If your worker processes are already based on OTP behaviours (like tr_server), then setting up a supervisor is pretty easy. What the standard OTP worker behaviours gen_server, gen_event, and gen_fsm do in order to be easily hooked in to a supervision tree isn’t deep magic—it mostly involves conforming to some interfaces and return-value conventions and setting up process links properly. Fortunately, it’s something you don’t need to know about; if you occasionally need to include code that isn’t based on a standard behaviour in the supervision tree, you can do so via the supervisor_bridge adapter in the standard library.

The one detail that we’ve left out is how to start a root supervisor, as required for the start/2 function of the application behaviour. The purpose of an active application is to run one or more processes to do some work. In order to have control over those processes, they should be spawned and managed by supervisors: processes that implement the supervisor behaviour.