• What is a exit signal?
  Except normal message passing, a process could send signal to other processes to let them know it is exiting. So, it is a special kind of message. Exit signal contains exit reason, so other processes could decide how to react.
  
• Processes are linked using exit signals
  A process could be linked with another process by subscribe to that process’s exit signal. All linked processes receive the exit signal from the terminating process.
  
• What does it mean by a process trapping exit?
  When a process traps exit (signals), the exit signals that are received from links will be converted into messages which are then put inside the mailbox.
  

• How to make a process trap exit?
  A normal process can trap exit signal by converting itself into system process.
  

  process_flag(trap_exit, true)
  

  A system process can handle exit signals because exit signals will be converted into message. So, system process could just use receive to handle them.
  

• What are the different reason for a process to terminate?
  
  1. A normal exit
     
  2. Unhandled errors
     
  3. Killed
     

1. Exception source: spawn_link(fun() -> ok end)
   
   • Untrapped result: - nothing -
     
   • Trapped result: {’EXIT’, <0.61.0>, normal}
     
   • The process exited normally, without a problem.
     
2. Exception source: spawn_link(fun() -> exit(reason) end)
   
   • Untrapped result: ** exception exit: reason
     
   • Trapped result: {’EXIT’, <0.55.0>, reason}
     
   • The process has terminated for a custom reason. If there is no trapped exit (using system process), the process crashed.
     
3. Exception source: spawn_link(fun() -> exit(normal) end)
   
   • Untrapped result: - nothing -
     
   • Trapped result: {’EXIT’, <0.58.0>, normal}
     
   • This emulates a process terminating normally.
     

1. Exception source: spawn_link(fun() -> 1/0 end)
   
   • Untrapped result: Error in process <0.44.0> with exit value: {badarith, [{erlang, ’/’, [1,0]}]}
     
   • Trapped result: {’EXIT’, <0.52.0>, {badarith, [{erlang, ’/’, [1,0]}]}}
     
   • The error is not caught by try...catch block and bubbles up into an ’EXIT’.
     
   • It behaves the same as exit(reason), with a stack trace giving more details about what happend.
     
2. Exception source: spawn_link(fun() -> erlang:error(reason) end)
   
   • Untrapped result: Error in process <0.47.0> with exit value: {reason, [{erlang, apply, 2}]}
     
   • Trapped result: {’EXIT’, <0.74.0>, {reason, [{erlang, apply, 2}]}}
     
   • Same as case 1) of Error. erlang/error/1 is meant to allow you to do just that.
     

Exception source: spawn_link(fun() -> throw(rocks) end)

• Untrapped result: Error in process <0.51.0> with exit value: {{nocatch, rocks}, [{erlang, apply, 2}]}
  
• Trapped result: {’EXIT’, <0.79.0>, {{nocatch, rocks}, [{erlang, apply, 2}]}}
  
• throw is not caught by try...catch, it bubbles up into an error –> an EXIT.
  

• Generated with exit/2, like a gun. It allows a process to kill another one from a distance.
  
• When using kill exit signal, it is used to forcefully terminate the receiving process even if it is trapping exits.
  
• When a process is killed with kill, it will emit exit signal killed to other linked process.
  

1. Exit signals with reason will terminate the receiving process unless it is trapping exits. In which case, it can convert exit signals into normal messages and be handled by receive.
   
2. normal exit signals are harmless.
   
   • When untrapped, they are ignoreed by receiving process.
     
   • When trapped, they are received as messages.
     
   • If it is sent by self, it will cause the process to terminal with a normal exit reason.
     
3. kill exit signals always terminate the receiving process even if it is trapping exits.
   

• Understanding Exit Signals in Erlang/Elixir
  

Suppose we have the following worker

-module(worker).
-compile([export_all]).

%% Run a worker
worker() ->
    io:format("I am worker ~p~n", [self()]),
    receive
	stop ->
	    io:format("received stop, so stop work now~n");
	Message -> 
	    io:format("receive: ~p~n", [Message]),
	    worker()
    after 2000 ->
	    worker()
    end.

We could create multiple monitor process and spawn_monitor for each worker process individually.

on_exit_aux(F) ->
    {Pid, Ref} = spawn_monitor(F),
    io:format("waiting message from{~p, ~p}~n", [Pid, Ref]),
    receive
	stop -> % this pattern makes us could stop workers by their monitoring process
	    io:format("stop monitored process ~p~n", [Pid]),
	    Pid ! stop; % stop worker process normally
	{'DOWN', Ref, process, Pid, normal} ->
	    io:format("~p exited, because of normal~n", [Pid]);
	{'DOWN', Ref, process, Pid, Why} ->
	    io:format("~p exited abnormally, because of ~p~n", [Pid, Why]),
	    on_exit_aux(F)
    end.
on_exit(F) ->
    spawn(fun () -> on_exit_aux(F) end).


%% L is a list of functions as worker
%% It returns a list of Pids which each of them monitor a worker and keep it a live.
cluster01(L) ->
    lists:reverse(cluster01(L, [])).
cluster01([], Acc)->
    Acc;
cluster01([H|T], Acc) ->
    cluster01(T, [on_exit(H)|Acc]).

stop_cluster01([]) ->
    void;
stop_cluster01([H|T]) ->
    spawn(fun () ->
		  H ! stop, % send stop to Pid, Pid could be monitor process or worker process
		  stop_cluster01(T)
	  end).

At last, we start them

q05(Num) ->
    observer:start(),
    lib_misc:cluster01([fun worker:worker/0 || _ <- lists:seq(1, Num)]).

Suppose, we use the same worker. Now, we prefer to create only one monitor process. And inside it, we spawn_monitor multiple worker processes.

create_workers(Num) ->
    Workers = [
	       %% {{Pid, Ref}, I}
	       spawn_monitor(worker, worker, []) || _ <- lists:seq(1, Num)
	      ],
    monitor_workers(Workers).

monitor_workers(Workers) ->
    io:format("~p monitoring workers ~p~n", [self(), Workers]),
    Pids = lists:map(fun ({Pid, Ref}) -> Pid end, Workers),

    receive
	stop -> % stop all workers
	    io:format("stop all workers~n"),
	    stop_workers(Pids);
	restart ->
	    io:format("restart all workers~n"),
	    restart_workers(Pids, nil);
	{'DOWN', Ref, process, Pid, normal} ->
	    io:format("~p exited, because of normal~n", [Pid]),
	    monitor_workers(Pids);
	{'DOWN', Ref, process, Pid, Why} ->
	    io:format("~p exited abnormally, because of ~p~n", [Pid, Why]),
	    io:format("restart all workers~n"),
	    restart_workers(Pids, Pid);
	_ ->
	    monitor_workers(Pids)
    end.

restart_workers(Pids, Pid) ->
    N = length(Pids),
    StoppingWorkers = lists:filter(fun (X) -> X =/= Pid end, Pids),
    stop_workers(StoppingWorkers),
    io:format("~p have been stopped~n", [StoppingWorkers]),
    spawn(fun () ->
		  create_workers(N)
	  end).

stop_workers(Pids) ->
    [Pid ! stop || Pid <- Pids].

Now, use them from main module

q06(Num) ->
    observer:start(),
    spawn(fun () ->  lib_misc:create_workers(Num) end).

spawn_monitor + receive...end once make me very confused. I either puth the monitor process keep waiting on shell, or doesn’t receive any message from monitor process when its monitoring process exit. The reasons are:

1. receive...end is synchronous, so it will make current process keep waiting. The solution is to spawn the monitor process from an anonymous function (lambda function).
   
2. spawn_monitor should be used with receive...end in the SAME process. So, after spawn_monitor we should NOT receive...end in another process (do NOT spawn an anonymous function for receive...end). Otherwise, you won’t receive messages sent to monitoring process, you are receiving messages sent to the anonymous function.
   
3. Just remember, spawn_monitor and receive...end must be used in the SAME process. Because what receive...end does is receiving the messages sent to the current process which is where spawn_monitor is called.
   
4. One clause of receive...end probably contains a recursive structure which does spawn_monitor to restart function some function F.