Explain the mechanism of actors models in Erlang (and sisters languages) , for processes managements in distributed systems.

1. ERLANG Supervisor
Concepts & Specs
Trung Nguyen 2018

2. Erlang/OTP high-level coordination
Concurrency built-in:
readily support 10,000 processes per core,
and transparent distribution of processes
across multiple machines,
using message passing for communication.

3. Erlang distribution model
The robustness of the Erlang is provided
by hierarchies of supervision processes
which manage recovery from software or hardware errors.

4. The standard Erlang/OTP behaviours are:
● Gen_server For implementing the server of a client-server relation
● Gen_statem For implementing state machines
● Gen_event For implementing event handling functionality
● Supervisor For implementing a supervisor in a supervision tree

5. Supervisor ->Use for controlling
Let the process die and correct the error
in some other process.
Remote detection and handling of errors.
Child process restarting rate after crash.

6. Supervisor’s raw structure is a MAP(sincev18)
{ #{ strategy => RestartStrategy,
intensity => MaxRestart ,
timeout => MaxTime},
[#{child_specs}]
}.

7. Supervisor structure : strategy
To prevent a supervisor from getting into an infinite loop
of child process terminations and restarts,
a maximum restart intensity is defined.
Assuming the values
MaxR for intensity (defaults =1 )
and MaxT for period (defaults =5).
If more than MaxR times of restarts occur within MaxT seconds,
the supervisor terminates all child processes and then itself.

8. Supervisor structure : strategy
one_for_one -> this is the default restart strategy.
one_for_all ->
rest_for_one ->
simple_one_for_one ->

9. Child specifications
The child specification can be described in a more abstract form as:
{ ChildId,
StartFunc,
Restart,
Shutdown,
Type,
Modules}.

10. Child specifications
child_spec() =
#{id => child_id(), % mandatory
start => mfargs(), % mandatory
restart => restart(), % optional
shutdown => shutdown(), % optional
type => worker(), % optional
modules => modules()} % optional

11. Child specifications : ChildId
The ChildId is just an internal name
used by the supervisor internally.
Any term can be used for the Id.

12. Child specifications: Restart strategy
restart defines when a terminated child process is to be restarted.
● A permanent child process is always restarted.
● A temporary child process is never restarted
(not even when the supervisor restart strategy is rest_for_one or one_for_all
and a sibling death causes the temporary process to be terminated).
● A transient child process is restarted only if it terminates abnormally
that is, with an exit reason other than normal, shutdown,
or {shutdown,Term}.

13. Child specifications : Restart order
When the supervisor is started, the child processes are started
in order from left to right according to this list.
When the supervisor terminates, it first terminates its child processes
in reversed start order, from right to left.
-> and then terminates itself.

14. Child specifications : Start Function
StartFunc is a tuple that tells how to start the child.
standard {M,F,A} format we've used a few times already.
USE ALWAYS gen_*:start_link() wrapped in your own module.

15. Child specifications : Shutdown
The Shutdown value used to give a deadline on the termination.
When a supervisor gets the shutdown signal,
it will forward it to its own children the same way.
When the top-level supervisor is asked to terminate, it calls
exit(ChildPid, shutdown) on each of the Pids.
If the child is a worker and trapping exits, it'll call its own terminate function.
Otherwise, it's just going to die.

16. Child specifications : Shutdown
Note is important : for simple_one_for_one strategy
With this behaviour , children are not respecting this rule
with the Shutdown time.
The supervisor will just exit ,
and it will be left to each of the workers to terminate on their own,
after their supervisor is gone.

17. Child specifications : Type
Type simply lets the supervisor know whether the child
is a worker or a supervisor.
This will be important when upgrading applications
with more advanced OTP features.

18. Child specifications : Module
Modules is a list of one element,
the name of the callback module used by the child behavior.

19. Child specifications : Module
The exception to that is when you have callback modules
whose identity you do not know beforehand
(such as event handlers in an event manager).
In this case, the value of Modules should be dynamic,
so that the whole OTP system knows who to contact
when using more advanced features, such as releases.

20. Behaviours
= formalizations of common patterns.
Divide a process code into
1/ a generic part (a behaviour module)
2/ and a specific part (a callback module).

21. Workers and Supervisors
hierarchical arrangement of code help
design and program fault-tolerant software

22. Restart strategies : one_for_one
If one child process terminates and is to be restarted,
only that child process is affected.

23. Restart strategies : one_for_one
%% Generate a generation of BirdName.
init(oone) ->
init({one_for_one, 5, 60});
init({RestartStrategy, MaxRestart, MaxTime}) ->
{ok, {{RestartStrategy, MaxRestart, MaxTime},
[{ChildSpecs_1},{ChildSpecs_2},..,{ChildSpecs_N}]}}.

24. Restart strategies : one_for_all ->
If one child process terminates and is to be restarted,
all other child processes are terminated
and then all child processes are restarted.

25. Restart strategies : one_for_all
%% Generate a generation of BirdName.
init(ofall) ->
init({one_for_all, 5, 60});
init({RestartStrategy, MaxRestart, MaxTime}) ->
{ok, {{RestartStrategy, MaxRestart, MaxTime},
[{ChildSpecs_1},{ChildSpecs_2},..,{ChildSpecs_N}]}}.

26. Restart strategies : rest_for_one ->
●
If one child process terminates and is to be restarted,
the 'rest' of the child processes are terminated.
(a dependency between processes according to their booting order.
if a child process dies, only those booted after it are killed.
Processes are then restarted as expected.)

27. Restart strategies : rest_for_all
%% Generate a generation of BirdName.
init(resto) ->
init({rest_for_all, 5, 60});
init({RestartStrategy, MaxRestart, MaxTime}) ->
{ok, {{RestartStrategy, MaxRestart, MaxTime},
[{ChildSpecs_1},{ChildSpecs_2},..,{ChildSpecs_N}]}}.

28. Restart strategies :simple_one_for_one
A simplified one_for_one supervisor, where all child processes are
dynamically added instances of the same process,
that is, running the same code template .
(same type=WORKER and same frequency of restart & shutdown timeout).
With this strategy, no workers are started during the supervisor initialization.
Instead, a worker is started manually via the
supervisor:start_child/2 function.

29. Restart strategies :simple_one_for_one
–Robert Virding rvirding explained:
You must define the child spec as it is used for all children
and you do not give it when starting a child.
In all other cases you do not need to give it as you must explicitly give a child
spec when you call supervisor:start_child/2.
The supervisor will automatically start the children with child specs returned in
the init/1 callback.
You can then add children using supervisor:start_child/2.

30. Restart strategies :simple_one_for_one
%%Supervisor ‘s unique child template
%%A fixedline phone example
init([]) ->
{ok, {{simple_one_for_one, 10, 3600},
[{ms, {phone_fsm, start_link, []},
transient, 2000, worker, [phone_fsm]}]}}.

31. Example : Supervisor with gen_FSM
A playground with birds

32. Example : Supervisor with gen_FSM

33. Example : Supervisor with gen_FSM
Creates a gen_fsm process as part of a supervision tree.
The function should be called, directly or indirectly, by the supervisor.
It will, among other things, ensure that the gen_fsm is linked to the supervisor.

34. Initialization : Worker descr
start_link(BirdName) ->
gen_fsm:start_link({local, BirdName}, ?MODULE, [BirdName], []).
init(Ms) ->
process_flag(trap_exit, true),
% % default state of worker set to GROWWING
{ok, growing, Ms}.

35. Example : Supervisor with gen_server
A musicians band