When to use timeouts and monitors in Erlang? - erlang

Question

The Learn You Some Erlang book has the below code. Why does the book sometimes use just timeouts and sometimes use both monitors and timeouts? In the below what is the need for the monitor since the timeout will effectively detect if the process is down?
%% Synchronous call
order_cat(Pid, Name, Color, Description) ->
Ref = erlang:monitor(process, Pid),
Pid ! {self(), Ref, {order, Name, Color, Description}},
receive
{Ref, Cat} ->
erlang:demonitor(Ref, [flush]),
Cat;
{'DOWN', Ref, process, Pid, Reason} ->
erlang:error(Reason)
after 5000 ->
erlang:error(timeout)
end.
Also compare the following where add_event doesn't use a monitor but subscribe does
subscribe(Pid) ->
Ref = erlang:monitor(process, whereis(?MODULE)),
?MODULE ! {self(), Ref, {subscribe, Pid}},
receive
{Ref, ok} ->
{ok, Ref};
{'DOWN', Ref, process, _Pid, Reason} ->
{error, Reason}
after 5000 ->
{error, timeout}
end.
add_event(Name, Description, TimeOut) ->
Ref = make_ref(),
?MODULE ! {self(), Ref, {add, Name, Description, TimeOut}},
receive
{Ref, Msg} -> Msg
after 5000 ->
{error, timeout}
end.

Answer 1

There is a big difference between those two examples.
order_cat(Pid, Name, Color, Description) uses a monitor for the duration of one request, and calls erlang:demonitor/2 after receiving a successful response.
subscribe(Pid) establishes a monitor more permanently. The intent is that the event client would receive the {'DOWN', Ref, process, Pid, Reason} message in its main receive block and handle the fact that the event server died. Note how subscribe(Pid) returns the monitor reference as {ok, Ref} for the client to use for this purpose. Unfortunately, the book doesn't show what the event client would look like.
Now as to the more general question about monitors vs. timeouts: The disadvantage of monitoring is a small additional cost, and a small amount of complexity. The advantages compared to timeouts include:
If the target process doesn't exist or crashes trying to handle the message you just sent, you find out immediately rather than after a timeout. For some applications, that time saved is very important.
If the target process crashes, the Reason part of the monitor message tells you something about why. In some applications, the client may try different recovery actions depending on the reason.
The sending process knows whether to expect a response from the target process in the future. In the case of a timeout, if the target process was merely slow to respond, the sending process will get a response in its mailbox. If the sender fails to clear such responses from its mailbox, it will become slow and eventually terminate. The book touches on this problem in the Selective Receive section. The gen_server:call/3 documentation also explains this issue briefly.
The implementation of gen_server:call/2 uses a monitor. Since this is how many production erlang requests are sent, you can trust that it is well optimized and the recommended default. In fact, you should be using OTP rather than rolling your own.
See the source code here. Here's the relevant function:
do_call(Process, Label, Request, Timeout) ->
try erlang:monitor(process, Process) of
Mref ->
%% If the monitor/2 call failed to set up a connection to a
%% remote node, we don't want the '!' operator to attempt
%% to set up the connection again. (If the monitor/2 call
%% failed due to an expired timeout, '!' too would probably
%% have to wait for the timeout to expire.) Therefore,
%% use erlang:send/3 with the 'noconnect' option so that it
%% will fail immediately if there is no connection to the
%% remote node.
catch erlang:send(Process, {Label, {self(), Mref}, Request},
[noconnect]),
receive
{Mref, Reply} ->
erlang:demonitor(Mref, [flush]),
{ok, Reply};
{'DOWN', Mref, _, _, noconnection} ->
Node = get_node(Process),
exit({nodedown, Node});
{'DOWN', Mref, _, _, Reason} ->
exit(Reason)
after Timeout ->
erlang:demonitor(Mref, [flush]),
exit(timeout)
end
catch
error:_ ->
%% Node (C/Java?) is not supporting the monitor.
%% The other possible case -- this node is not distributed
%% -- should have been handled earlier.
%% Do the best possible with monitor_node/2.
%% This code may hang indefinitely if the Process
%% does not exist. It is only used for featureweak remote nodes.
Node = get_node(Process),
monitor_node(Node, true),
receive
{nodedown, Node} ->
monitor_node(Node, false),
exit({nodedown, Node})
after 0 ->
Tag = make_ref(),
Process ! {Label, {self(), Tag}, Request},
wait_resp(Node, Tag, Timeout)
end
end.

Answer 2

Why does the book sometimes use just timeouts and sometimes use both monitors and timeouts?
The process may terminate before the timeout expires, but you don’t want to wait longer for no reason. You want the call to take at most five seconds, not always five seconds.
In the below what is the need for the monitor since the timeout will effectively detect if the process is down?
It won’t; terminations don’t trigger timeouts, time does.