Error Handling

• Definitions
• Exit signals are sent when processes crash
• Exit Signals propagate through Links
• Processes can trap exit signals
• Complex Exit signal Propagation
• Robust Systems can be made by Layering
• Primitives For Exit Signal Handling
• A Robust Server
• Allocator with Error Recovery
• Allocator Utilities

Definitions

• Link A bi-directional propagation path for exit signals.
• Exit Signal - Transmit process termination information.
• Error trapping - The ability of a process to process exit signals as if they were messages.

back to top

Exit Signals are Sent when Processes Crash

back to top

Exit Signals propagate through Links

Now suppose process A fails - exit signals start to propogate through the links:

These exit signals eventuall reach all the processes which are linked together.

The rule for propagating errors is: If the process which receives an exit signal, caused by an error, is not trapping exits then the process dies and sends exit signals to all its linked processes.

back to top

Processes can trap exit signals

P2 has the following code:

receive
    {'EXIT', P1, Why} ->
	... exit signals ...
    {P3, Msg} ->
	... normal messages ...
end

back to top

Complex Exit signal Propagation

The process marked with a double ring is an error trapping process.

If an error occurs in any of A, B, or C then All of these process will die (through propagation of errors). Process D will be unaffected.

back to top

Exit Signal Propagation Semantics

• When a process terminates it sends an exit signal, either normal or non-normal, to the processes in its link set.
• A process which is not trapping exit signals (a normal process) dies if it receives a non-normal exit signal. When it dies it sends a non-normal exit signal to the processes in its link set.
• A process which is trapping exit signals converts all incoming exit signals to conventional messages which it can receive in a receive statement.
• Errors in BIFs or pattern matching errors send automatic exit signals to the link set of the process where the error occured.

back to top

Robust Systems can be made by Layering

In a well designed system we can arrange that application programers will not have to write any error handling code since all error handling is isolated to deper levels in the system.

back to top

Primitives For Exit Signal Handling

• link(Pid) - Set a bi-directional link between the current process and the process Pid
• process_flag(trap_exit, true) - Set the current process to convert exit signals to exit messages, these messages can then be received in a normal receive statement.
• exit(Reason) - Terminates the process and generates an exit signal where the process termination information is Reason.

The receive .. end construct attempts to remove messages from the mailbox of the current process. Exit signals which arrive at a process either cause the process to crash (if the process is not trapping exit signals) or are treated as normal messages and placed in the process mailbox (if the process is trapping exit signals). Exit signals are sent implicitly (as a result of evaluating a BIF with incorrect arguments) or explicitly (using exit(Pid, Reason), or exit(Reason) ).

If Reason is the atom normal - the receiving process ignores the signal (if it is not trapping exits). When a process terminates without an error it sends normal exit signals to all linked processes. Don't say you didn't ask!

back to top

A Robust Server

This is unreliable - What happens if the client crashes before it sends the release message?

top(Free, Allocated) ->
    receive
	{Pid, alloc} ->
	    top_alloc(Free, Allocated, Pid);
	{Pid ,{release, Resource}} ->
	    Allocated1 = delete({Resource,Pid},�Allocated),
    	    top([Resource|Free], Allocated1)
    end.

top_alloc([], Allocated, Pid) ->
    Pid ! no,
    top([], Allocated);

top_alloc([Resource|Free], Allocated, Pid) ->
    Pid ! {yes, Resource},
    top(Free, [{Resource,Pid}|Allocated]).

back to top

Allocator with Error Recovery

The server is linked to the client during the time interval when the resource is allocted. If an exit message comes from the client during this time the resource is released.

top_recover_alloc([], Allocated, Pid) ->
    Pid ! no,
    top_recover([], Allocated);

top_recover_alloc([Resource|Free], Allocated, Pid) ->
    %% No need to unlink.
    Pid ! {yes, Resource},
    link(Pid),
    top_recover(Free, [{Resource,Pid}|Allocated]).

top_recover(Free, Allocated) ->
    receive
	{Pid , alloc}�->
	    top_recover_alloc(Free, Allocated, Pid);
	{Pid, {release, Resource}}�->
	    unlink(Pid),
 	    Allocated1 = delete({Resource, Pid}, Allocated),
	    top_recover([Resource|Free], Allocated1);
	{'EXIT', Pid, Reason}�->
	    %% No need to unlink.
	    Resource = lookup(Pid, Allocated),
	    Allocated1 = delete({Resource, Pid}, Allocated),
	    top_recover([Resource|Free], Allocated1)
    end.

back to top

Allocator Utilities

delete(H, [H|T]) ->
    T;
delete(X, [H|T]) ->
    [H|delete(X, T)].

lookup(Pid, [{Resource,Pid}|_]) ->
    Resource;
lookup(Pid, [_|Allocated]) ->
    lookup(Pid, Allocated).

back to top