<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">
<chapter>
<header>
<copyright>
<year>2012</year><year>2016</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</legalnotice>
<title>Communication in Erlang</title>
<prepared>Rickard Green</prepared>
<responsible></responsible>
<docno></docno>
<approved>uy</approved>
<checked></checked>
<date>2012-12-03</date>
<rev>PA1</rev>
<file>communication.xml</file>
</header>
<p>Communication in Erlang is conceptually performed using
asynchronous signaling. All different executing entities,
such as processes and ports, communicate through asynchronous
signals. The most commonly used signal is a message. Other
common signals are exit, link, unlink, monitor, and demonitor
signals.</p>
<section>
<title>Passing of Signals</title>
<p>The amount of time that passes between a signal is sent
and the arrival of the signal at the destination is unspecified
but positive. If the receiver has terminated, the signal does
not arrive, but it can trigger another signal.
For example, a link signal sent to a non-existing process
triggers an exit signal, which is sent back to where the link
signal originated from. When communicating over the distribution,
signals can be lost if the distribution channel goes down.</p>
<p>The only signal ordering guarantee given is the following: if
an entity sends multiple signals to the same destination entity,
the order is preserved; that is, if <c>A</c> sends
a signal <c>S1</c> to <c>B</c>, and later sends
signal <c>S2</c> to <c>B</c>, <c>S1</c> is guaranteed not to
arrive after <c>S2</c>.</p>
</section>
<section>
<title>Synchronous Communication</title>
<p>Some communication is synchronous. If broken down into pieces,
a synchronous communication operation consists of two asynchronous
signals; one request signal and one reply signal. An example of
such a synchronous communication is a call to
<seealso marker="erlang:process_info/2">
<c>erlang:process_info/2</c></seealso>
when the first argument is not <c>self()</c>. The caller sends
an asynchronous signal requesting information, and then
waits for the reply signal containing the requested information. When
the request signal reaches its destination, the destination process
replies with the requested information.</p>
</section>
<section>
<title>Implementation</title>
<p>The implementation of different asynchronous signals in the virtual
machine can vary over time, but the behavior always respects this
concept of asynchronous signals being passed between entities
as described above.</p>
<p>By inspecting the implementation, you might notice that some
specific signal gives a stricter guarantee than described
above. It is of vital importance that such knowledge about the
implementation is <em>not</em> used by Erlang code, as the
implementation can change at any time without prior notice.</p>
<p>Examples of major implementation changes:</p>
<list type="bulleted">
<item>As from <c>ERTS</c> 5.5.2 exit signals to processes are truly
asynchronously delivered.</item>
<item>As from <c>ERTS</c> 5.10 all signals from processes to ports
are truly asynchronously delivered.</item>
</list>
</section>
</chapter>
