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.

Invest now in Acorns!!! 🚀
Join Acorns and get your $5 bonus!

Acorns is a micro-investing app that automatically invests your "spare change" from daily purchases into diversified, expert-built portfolios of ETFs. It is designed for beginners, allowing you to start investing with as little as $5. The service automates saving and investing. Disclosure: I may receive a referral bonus.

Invest now!!! Get Free equity stock (US, UK only)!

Use Robinhood app to invest in stocks. It is safe and secure. Use the Referral link to claim your free stock when you sign up!.

The Robinhood app makes it easy to trade stocks, crypto and more.

Webull! Receive free stock by signing up using the link: Webull signup.