diff options
Diffstat (limited to 'erts/doc/src/communication.xml')
| -rw-r--r-- | erts/doc/src/communication.xml | 69 |
1 files changed, 39 insertions, 30 deletions
diff --git a/erts/doc/src/communication.xml b/erts/doc/src/communication.xml index 3deea3e4af..7e18a73aa8 100644 --- a/erts/doc/src/communication.xml +++ b/erts/doc/src/communication.xml @@ -4,7 +4,7 @@ <chapter> <header> <copyright> - <year>2012</year><year>2013</year> + <year>2012</year><year>2016</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> @@ -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 ERTS 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 ERTS 5.10 all signals from processes to ports are truly asynchronously delivered.</item> </list> </section> |