Home > DeveloperSection > Blogs > What is Supervisor in Erlang?

What is Supervisor in Erlang?


erlang Functional Programming  OTP  erlang 
Ratings:
0 Comment(s)
 554  View(s)
Rate this:


Supervisor in Erlang


Supervisors are processes which monitor the behaviour of workers. A supervisor can restart a worker if something goes wrong.The supervisor is responsible for starting, stopping and monitoring its child processes. Workers are processes which perform computations .


A supervisor can supervise either workers or supervisors. Hereafter we will use the term child to mean either a worker or a supervisor.



Supervision trees can be manipulated by using the functions exported from the module supervisor


A typical supervision tree looks as follows:


sup6



The square boxes represent supervisors.

The circles represent workers.


The properties of a supervisor are defined by the supervisor flags. This is the type definition for the supervisor flags:

sup_flags() = #{strategy => strategy(),         
                intensity => non_neg_integer(), 
                period => pos_integer()} 

These flags are option.

Supervisors restart strategies strategy key are-
      
  • one_for_one - if one child process terminates and should be restarted, only that child process is affected. This is the default restart strategy.


  • one_for_all - if one child process terminates and should be restarted, all other child processes are terminated and then all child processes are restarted.


  • rest_for_one - if one child process terminates and should be restarted, the 'rest' of the child processes -- i.e. the child processes after the terminated child process in the start order -- are terminated. Then the terminated child process and all child processes after it are restarted.


  • simple_one_for_one - a simplified one_for_one supervisor, where all child processes are dynamically added instances of the same process type, i.e. running the same code.



To prevent a supervisor from getting into an infinite loop of child process terminations and restarts, a maximum restart intensity is defined using two integer values specified with the intensity and period keys in the above map. Assuming the values MaxR for intensity and MaxT for period, then if more than MaxR restarts occur within MaxT seconds, the supervisor will terminate all child processes and then itself. The default value for intensity is 1, and the default value for period is 5.



This is the type definition of a child specification:


child_spec() = #{id => child_id(),       
                 start => mfargs(),      
                 restart => restart(),  
                 shutdown => shutdown(), 
                 type => worker(),       
                 modules => modules()}   


id is used to identify the child specification internally by the supervisor.


    The id key is mandatory.


    Note that this identifier on occations has been called "name". As far as possible, the terms "identifier" or "id" are now used but in order to keep backwards compatibility, some occurences of "name" can still be found, for example in error messages.


    start defines the function call used to start the child process. It must be a module-function-arguments tuple {M,F,A} used as apply(M,F,A).

  • The start function must create and link to the child process, and must return {ok,Child} or {ok,Child,Info} where Child is the pid of the child process and Info an arbitrary term which is ignored by the supervisor.

  • The start function can also return ignore if the child process for some reason cannot be started, in which case the child specification will be kept by the supervisor (unless it is a temporary child) but the non-existing child process will be ignored.

    If something goes wrong, the function may also return an error tuple {error,Error}.

    Note that the start_link functions of the different behaviour modules fulfill the above requirements.

    The start key is mandatory.

  • restart defines when a terminated child process shall be restarted. A permanent child process will always be restarted, a temporary child process will never be restarted (even when the supervisor's restart strategy is rest_for_one or one_for_all and a sibling's death causes the temporary process to be terminated) and a transient child process will be restarted only if it terminates abnormally, i.e. with another exit reason than normal, shutdown or {shutdown,Term}.

    The restart key is optional. If it is not given, the default value permanent will be used.

  • shutdown defines how a child process shall be terminated. brutal_kill means the child process will be unconditionally terminated using exit(Child,kill). An integer timeout value means that the supervisor will tell the child process to terminate by calling exit(Child,shutdown) and then wait for an exit signal with reason shutdown back from the child process. If no exit signal is received within the specified number of milliseconds, the child process is unconditionally terminated using exit(Child,kill).

    If the child process is another supervisor, the shutdown time should be set to infinity to give the subtree ample time to shut down. It is also allowed to set it to infinity, if the child process is a worker.

    Note that all child processes implemented using the standard OTP behaviour modules automatically adhere to the shutdown protocol.

    The shutdown key is optional. If it is not given, the default value 5000 will be used if the child is of type worker; and infinity will be used if the child is of type supervisor.

  • type specifies if the child process is a supervisor or a worker.

    The type key is optional. If it is not given, the default value worker will be used.

  • modules is used by the release handler during code replacement to determine which processes are using a certain module. As a rule of thumb, if the child process is a supervisor, gen_server, or gen_fsm, this should be a list with one element [Module], where Module is the callback module. If the child process is an event manager (gen_event) with a dynamic set of callback modules, the value dynamic shall be used. See OTP Design Principles for more information about release handling.

    The modules key is optional. If it is not given, it defaults to [M], where M comes from the child's start {M,F,A}

  • Internally, the supervisor also keeps track of the pid Child of the child process, or undefined if no pid exists.





Don't want to miss updates? Please click the below button!

Follow MindStick