Erlang / Erlang Advanced Interview questions
Why would you choose monitor over link for a client process?
A client that calls into a server it doesn't own — say, a request handler calling a shared cache
process — usually shouldn't die just because that server crashed. Using monitor/2 instead
of link/1 gets you the crash notification without coupling the client's own lifecycle to the
server's.
Ref = erlang:monitor(process, ServerPid), ServerPid ! {self(), get_data}, receive {'DOWN', Ref, process, ServerPid, Reason} -> handle_server_down(Reason); {ok, Data} -> erlang:demonitor(Ref, [flush]), Data end.
Links are the right tool when the two processes are meant to live and die together — a supervisor and
its worker, or two halves of one logical unit. Monitors are the right tool for arm's-length relationships,
like gen_server:call's internal use of a monitor so a caller learns about a dead server without
risking being killed by it.
More Related questions...