Erlang monitoring tree Supervisor

Supervisor behaviour is a module used to implement a supervisor process to monitor other sub-processes.
A sub-process can be another supervisor or a worker process.
Generally, worker processes use gen_event, gen_fsm, or gen_server behaviour.
A supervisor implemented by this module has a standard set of interface methods, including the tracking and error reporting functions.
The supervisor is used to build a layered process structure called the supervision tree, which is a good way to organize a fault-tolerant system.

1. Supervision Principle
Supervisor is responsible for starting, stopping, and monitoring its sub-Processes
If necessary, the supervisor restarts its sub-processes to keep them alive.
The sub-supervisor is defined as a list of sub-Specifications.
When the supervisor starts, the sub-process starts in the order of list from left to right.
When a supervisor terminates, it first terminates its sub-processes in the reverse order of startup.

2. Example
Start the callback module of the supervisor of the server:

-module(ch_sup).-behaviour(supervisor). -export([start_link/0]).-export([init/1]). start_link() ->  supervisor:start_link(ch_sup, []). init(_Args) ->  {ok, {{one_for_one, 1, 60},    [{ch3, {ch3, start_link, []},      permanent, brutal_kill, worker, [ch3]}]}}.

One_for_one is one of the restart policies.
1 and 60 define the maximum restart frequency
Tuple {CH3 ,...} Yes sub-Specification

3. Restart Policy
3.1 one_for_one
If a sub-process is stopped, only the process is restarted.

3.2 one_for_all
If a sub-process stops, all other sub-processes also stop, and then all processes restart

3.3 rest_for_one
If a sub-process is stopped, all other sub-processes following the sub-process are also stopped in the startup sequence, and the stopped sub-processes are restarted (different from the one upstairs)
3.4 simple_one_for_one
A simplified one_for_one supervisor. All Sub-processes belong to the same process type and are dynamically added instances.

4. Maximum restart frequency
Supervisor has a built-in mechanism to limit the number of restarts within a given time period
This is determined by the two parameters maxr and maxt.

init(...) ->  {ok, {{RestartStrategy, MaxR, MaxT},    [ChildSpec, ...]}}.

If maxcompute restarts more than once in the last maxt seconds, the supervisor stops itself and all its sub-processes.
After the supervisor is stopped, the next more advanced supervisor performs the next action to restart the stopped supervisor or terminate the supervisor.
The purpose of the restart mechanism is to prevent a process from repeatedly killing for some reason.

5. Sub-Specifications
This is the type definition of the sub-specification:

Module = atom(){Id, StartFunc, Restart, Shutdown, Type, Modules}  Id = term()  StartFunc = {M, F, A}    M = F = atom()    A = [term()]  Restart = permanent | transient | temporary  Shutdown = brutal_kill | integer() >=0 | infinity  Type = worker | supervisor  Modules = [Module] | dynamic    Module = atom()

ID is the name used by the supervisor to internally identify sub-Specifications.
Startfunc defines the method used to subscribe the process, which complies with module-function-arguments tuple {M, F,}
It should call the supervisor: start_link, gen_server: start_link, gen_fsm: start_link or gen_event: start_link, or the appropriate method.
Restart defines when the sub-process restarts.
1) Permanent indicates that the sub-process is always restarted.
2) Temporary indicates that the sub-process will never restart
3) transient indicates that the sub-process is restarted only when the sub-process ends abnormally, that is, the reason for termination except normal.
Shutdown defines how sub-processes are terminated
1) brutal_kill indicates that the child process uses exit (child, kill) to terminate unconditionally.
2) an integer timeout value indicates that the supervisor tells the sub-process to terminate by calling exit (child, shutdown), and then waits for an exit signal to return
If the exit signal is not received within the specified time, the child process uses exit (child, kill) to terminate the operation unconditionally.
3) If the sub-process is another supervisor, it should be set to infinity to give the sub-tree enough time to terminate.
Type indicates whether the sub-process is a supervisor or a worker.
Modules should be a list containing an element [module]
If the sub-process is a supervisor, gen_server or gen_fsm, the module is the name of the callback module.
If the sub-process is a gen_event, modules should be dynamic
This information is used by release handler during upgrade and downgrade.
Example: subspecification for starting server CH3

{ch3,  {ch3, start_link, []},  permanent, brutal_kill, worker, [ch3]}

Example: Start the sub-Specification of event manager

{error_man,  {gen_event, start_link, [{local, error_man}]},  permanent, 5000, worker, dynamic}

Both the server and event manager are registration processes that can be accessed at any time so that they are specified as permanent
CH3 does not need to perform any cleanup before termination, so it does not need timeout, but it must meet brutal_kill. error_man may need some time for event handler to clean up, So shutdown is set to 5000 Ms.
Example: Start the sub-Specification of another supervisor

{sup,  {sup, start_link, []},  transient, infinity, supervisor, [sup]}

6. Start a supervisor.
In the preceding example, the supervisor is started by calling ch_sup: start_link:

start_link() ->  supervisor:start_link(ch_sup, []).

Ch_sup: start_link call method Supervisor: start_link/2. This method starts a new supervisor process and connects to it.
1) The first parameter ch_sup is the name of the callback module, which is the location of the init callback method.
2) The second parameter [] is the parameter passed to the init callback method.
A supervisor process calls the callback method ch_sup: Init ([]) and returns {OK, statespec }:

init(_Args) ->  {ok, {{one_for_one, 1, 60},    [{ch3, {ch3, start_link, []},      permanent, brutal_kill, worker, [ch3]}]}}.

Start all its sub-processes according to the specified sub-standard entry. Here there is a sub-process CH3
Note that the supervisor: start_link is a synchronization belt and will be returned only after a sub-process is started.

7. Add a sub-process
In addition to static supervision tree, we can also add dynamic sub-processes to existing supervisors:

supervisor:start_child(Sup, ChildSpec)

Sup is the PID or name of the supervisor, and childspec is a sub-Specification
Child processes added using start_child/2 behave like other child processes. Except for this: if the supervisor dies and then restarts, all dynamically added child processes will be lost.

8. Stop a sub-process.
Any sub-process, whether static or dynamic, can be stopped using the shutdown specification:

supervisor:terminate_child(Sup, Id)

The sub-rules of stopped sub-processes are deleted using the following call:

supervisor:delete_child(Sup, Id)

Sup is the PID or name of the supervisor, and ID is the ID specified in the sub-specification.
Like a dynamically added sub-process, if the supervisor restarts, the effect of deleting a static sub-process will be lost.

9, simple_one_for_one Supervisor
The supervisor of the simple_one_for_one restart policy is a simplified one_for_one supervisor. All Sub-processes are dynamically added to instances of the same process.
An example of simple_one_for_one supervisor callback module:

-module(simple_sup).-behaviour(supervisor). -export([start_link/0]).-export([init/1]). start_link() ->  supervisor:start_link(simple_sup, []). init(_Args) ->  {ok, {{simple_one_for_one, 0, 1},    [{call, {call, start_link, []},      temporary, brutal_kill, worker, [call]}]}}.

-module(simple_sup).-behaviour(supervisor). -export([start_link/0]).-export([init/1]). start_link() ->  supervisor:start_link(simple_sup, []). init(_Args) ->  {ok, {{simple_one_for_one, 0, 1},    [{call, {call, start_link, []},      temporary, brutal_kill, worker, [call]}]}}.

After the supervisor starts, it does not start any sub-processes. Instead, it dynamically adds all sub-processes by calling the following code:

supervisor:start_child(Sup, List)

Sup is the PID or name of the supervisor, and list is an arbitrary term list, which will be dynamically added to the sub-standard parameter list.
If the start method is set to {M, F, a}, the sub-process starts by calling apply (M, F, a ++ list ).
For example, add a sub-process to simple_sup:

supervisor:start_child(Pid, [id1])

This will start the process by calling apply (call, start_link, [] ++ [id1]) or call: start_link (id1 ).

10. Termination
Since a supervisor is part of a supervision tree, it is automatically terminated by its supervisor.
When it is terminated, it will automatically terminate all its sub-processes in the reverse order of startup according to the corresponding shudown specifications, and then terminate itself

Supplement: Supervisor exports and callbacks

supervisor module                  Callback modulesupervisor:start_link              Module:init/1supervisor:start_childsupervisor:terminate_childsupervisor:delete_childsupervisor:restart_childsupervisor:which_childrensupervisor:check_childspecs

From: http://hideto.javaeye.com/blog/232618
I sincerely thank the author for his contribution. I will take a note here.