Tracking processes and error handling, part 3

Preamble

In the previous sections ( Part 1 , Part 2 ), we fully considered the mechanism for creating bidirectional connections between processes and the process of propagating errors. This article will examine, quite simple, the mechanism of monitors and several other aspects related to working with processes.

Monitors

Functions for working with monitors

A small list of functions that may be needed to work with monitors:

• erlang: monitor / 2 - the process calling the function starts monitoring the specified process;
• erlang: demonitor / 1/2 - disable the monitoring function;
• erlang: spawn_monitor / 1/3 - create a new process and bind the calling process to a function as a monitor.

If the observed process fails, the monitor receives the message {'DOWN', Reference, process, Pid, ​​Reason}, where

1. 'DOWN' - means that the process has dropped;
2. Reference - reference to the monitor;
3. process - the object of monitoring is the process (it is written in the documentation that in the current version of erlang, only processes can be monitored, perhaps in the future they will screw something else);
4. Pid - Pid of the fallen process;
5. Reason is the reason.

One of the differences between creating a connection and a monitor is that if you try to create a connection with a nonexistent process, the calling process will fall, and in the case of a monitor you will immediately receive the message {'DOWN', Reference, process, Pid, ​​Reason}. Let's try it in practice - run eshall and execute the following commands.

(emacs@aleksio-mobile)1> self(). <0.36.0> (emacs@aleksio-mobile)2> erlang:link(c:pid(0,777,0)). ** exception error: no such process or port in function link/1 called as link(<0.777.0>) (emacs@aleksio-mobile)3> self(). <0.39.0> (emacs@aleksio-mobile)4> flush(). ok (emacs@aleksio-mobile)5> erlang:monitor(process, c:pid(0,777,0)). #Ref<0.0.0.43> (emacs@aleksio-mobile)6> self(). <0.39.0> (emacs@aleksio-mobile)7> flush(). Shell got {'DOWN',#Ref<0.0.0.43>,process,<0.777.0>,noproc} ok (emacs@aleksio-mobile)8> 

')
In the first line, we recognize the Pid of the shell, then we try to associate the current process with a erlang: link (c: pid (0.777.0)) that is not known to exist, after which the shell falls off, the message queue is empty. With the fifth command, we call the erlang: monitor (process, c: pid (0.777.0)) function, which creates and returns a reference to the monitor. Since the process with Pid = <0.777.0> does not exist, the message {'DOWN', # Ref <0.0.0.43>, process, <0.777.0>, noproc} comes to the shell queue, which tells us that the process is <0.777 .0> not in the system.

We will write a small module to consolidate knowledge about monitors.

 -module(testm). -export([start_m/0, stop_m/1, loop/1]). start_m() -> erlang:spawn_monitor(?MODULE, loop, [self()]). stop_m(Ref) -> erlang:demonitor(Ref). loop(Shell) -> receive kill -> exit(kill); reason -> exit("Another reason"); Msg -> Shell ! {get_msg, Msg} end. 

The spawn_monitor function creates a process with a loop body and makes the calling process (in our example shell) a monitor.

 (emacs@aleksio-mobile)2> {Pid, Ref} = testm:start_m(). {<0.43.0>,#Ref<0.0.0.62>} ###  <0.43.0>,    #Ref<0.0.0.62> (emacs@aleksio-mobile)3> Pid ! hello. hello ###   (emacs@aleksio-mobile)4> flush(). Shell got {get_msg,hello} Shell got {'DOWN',#Ref<0.0.0.62>,process,<0.43.0>,normal} ok ###      {get_msg,hello} ###      normal (emacs@aleksio-mobile)5> f(Pid), f(Ref). ok ###  Pid  Ref  ###    (emacs@aleksio-mobile)6> {Pid, Ref} = testm:start_m(). {<0.48.0>,#Ref<0.0.0.77>} (emacs@aleksio-mobile)7> Pid ! kill. kill (emacs@aleksio-mobile)8> flush(). Shell got {'DOWN',#Ref<0.0.0.77>,process,<0.48.0>,kill} ok (emacs@aleksio-mobile)9> f(Pid), f(Ref). ok (emacs@aleksio-mobile)10> {Pid, Ref} = testm:start_m(). {<0.53.0>,#Ref<0.0.0.91>} (emacs@aleksio-mobile)11> Pid ! reason. reason (emacs@aleksio-mobile)12> flush(). Shell got {'DOWN',#Ref<0.0.0.91>,process,<0.53.0>,"Another reason"} ok (emacs@aleksio-mobile)13> testm:stop_m(Ref). true (emacs@aleksio-mobile)14> 

Question to readers: as you noticed with each new process creation, the link to the monitor is also new, but we did only turn off the monitor at the end. Will the previous links remain somewhere in the state of our process and can this somehow affect the work?

Conclusion

We considered monitors - a fairly convenient and simple mechanism for tracking the status of other processes. I hope everyone will be able to apply them in their tasks implemented in the Erlang language.

What to read?

1. Excellent online documentation .
2. ERLANG Programming by Francesco Cesarini and Simon Thompson.
3. Article on RSDN: error handling in Erlang .