Distributed mechanisms

The following BIFs are used for distributed programming:

spawn(Node, Mod, Func, Args)

Spawns a process on a remote node.

spawn_link(Node, Mod, Func, Args)

Spawns a process on a remote node and creates a link to the process.

monitor_node(Node, Flag)

If Flag is true, this BIF makes the evaluating process monitor the node

Node. If Node should fail or be nonexistent, a {nodedown, Node} message will be sent to the evaluating process. IfFlagisfalse, monitoring is turned off.

node()

Returns our own node name.

nodes()

Returns a list of the other known node names.

node(Item)

Returns the node name of the origin of Item where Item can be a Pid, reference or a port.

disconnect_node(Nodename)

Disconnects us from the nodeNodename.

Thenode is a central concept in distributedErlang. In a distributed Erlang

system the term node means an executing Erlang system which can take part

in distributed transactions. An individual Erlang system becomes part of a

distributed Erlang system by starting a special process called the net kernel.

This process evaluates the BIF alive/2. The net kernel is described in ??. Once the net kernel is started, the system is said to be alive.

Once the system is alive, a node name is assigned to it, this name is returned by the BIFnode(). This name is an atom and it is guaranteed to be globally unique. The format of the name can differ between different implementations ofErlang

but it is always an atom consisting of two parts separated by an ’@’character. The BIF node(Item) where Item is a Pid, port or reference returns the name of the node where Item was created. For example, if Pid is a process identifier,

node(Pid) returns the name of the node where Pidwas started.

The BIFnodes/0 returns a list of all other nodes in the network which we are currently connected to.

Distributed mechanisms 87

The BIF monitor_node(Node, Flag) can be used to monitor nodes. An Er- langprocess evaluating the expression _{monitor_node(Node, true)} will be noti-

fied with a {nodedown, Node} message if Node fails or if the network connection toNodefails. Unfortunately it is not possible to differentiate between node failures and network failures. For example, the following code suspends until the node

Node fails: ... monitor_node(Node, true), receive {nodedown, Node} -> ... end, ...

If no connection exists, and monitor_node/2 is called, the system will try to setup a connection and deliver anodedown message if the connection fails. If two consecutive monitor_node/2 calls are performed with the same node then two

nodedown messages will be delivered if the node fails.

A call tomonitor_node(Node, false) will only decrement a counter, indicat- ing the number of nodedown messages that should be delivered to the calling process if Node fails. The reason for this behavior is that we often want to en- capsulate remote calls within a matching pair of monitor_node(Node, true)and

monitor_node(Node, false).

The BIFs spawn/3 and spawn_link/3 create new processes on the local node. To create a new process on an arbitrary node we use the BIF spawn/4, so:

Pid = spawn(Node, Mod, Func, Args),

spawns a process onNode and spawn_link/4 spawns a linked process on a remote node.

A Pid is returned, which can be used in the normal manner. If the node does not exist a Pid is returned but in this case the Pid is not of much use since obviously no process is running. In the case ofspawn_link/4 an ’EXIT’ signal will be sent to the originating process if the node does not exist.

Almost all operations which are normally allowed on Pids are allowed on remote Pids as well. Messages can be sent to remote processes and links can be created between local and remote processes just as if the processes were executing on a local node. Another property of remote Pids is that sending messages to a remote process is syntactically and semantically identical to sending to a local process. This means, for example, that messages to remote process are always delivered in the same order they were sent, never corrupted and never lost. This is all taken care of by the run-time system. The only error control of message reception which is possible, is by thelinkmechanism which is under the control of the programmer or by explicitly synchronizing the sender and receiver of a message.

6.3

Registered Processes

The BIF register/2 is used to register a process by name on a local node. To send a message to a registered process on a remote node we use the notation:

{Name, Node} ! Mess.

If there is a process registered as Name on node Node, then Mess will be sent to that process. If the node or the registered process does not exist, the message will be lost. The registration of global names among a set of nodes is discussed in Section ??.