aboutsummaryrefslogtreecommitdiffstats
path: root/erts/doc/src/communication.xml
diff options
context:
space:
mode:
Diffstat (limited to 'erts/doc/src/communication.xml')
-rw-r--r--erts/doc/src/communication.xml67
1 files changed, 38 insertions, 29 deletions
diff --git a/erts/doc/src/communication.xml b/erts/doc/src/communication.xml
index 1eb05310e9..632ca6c212 100644
--- a/erts/doc/src/communication.xml
+++ b/erts/doc/src/communication.xml
@@ -26,63 +26,72 @@
<prepared>Rickard Green</prepared>
<responsible></responsible>
<docno></docno>
- <approved></approved>
+ <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 via asynchronous
+ 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, demonitor
+ 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 being sent
+ <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 will
- not arrive, but it is possible that it triggers another signal.
- For example, a link signal sent to a non-existing process will
- trigger an exit signal which will be sent back to where the link
+ 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 may be lost if the distribution channel goes down.</p>
- <p>The only signal ordering guarantee given is the following. If
+ 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 will be preserved. That is, if <c>A</c> sends
+ the order is preserved; that is, if <c>A</c> sends
a signal <c>S1</c> to <c>B</c>, and later sends
- the signal <c>S2</c> to <c>B</c>, <c>S1</c> is guaranteed not to
+ 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 <c>process_info/2</c>
- when the first argument is not <c>self()</c>. The caller will send
- an asynchronous signal requesting information, and will then
- wait for the reply signal containing the requested information. When
- the request signal reaches its destination the destination process
+ 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
- VM may vary over time, but the behaviour will always respect this
+ <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 actually gives a stricter guarantee than described
+
+ <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, since the
- implementation might change at any time without prior notice.</p>
- <p>Some example of major implementation changes:</p>
+ 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 of ERTS version 5.5.2 exit signals to processes are truly
+ <item>As from <c>ERTS</c> 5.5.2 exit signals to processes are truly
asynchronously delivered.</item>
- <item>As of ERTS version 5.10 all signals from processes to ports
+ <item>As from <c>ERTS</c> 5.10 all signals from processes to ports
are truly asynchronously delivered.</item>
</list>
</section>