Merge branch 'rickard/port-optimizations/OTP-10336' into rickard/r16/port-optimizations/OTP-10336

* rickard/port-optimizations/OTP-10336:
  Change annotate level for emacs-22 in cerl
  Update etp-commands
  Add documentation on communication in Erlang
  Add support for busy port message queue
  Add driver callback epilogue
  Implement true asynchronous signaling between processes and ports
  Add erl_drv_[send|output]_term
  Move busy port flag
  Use rwlock for driver list
  Optimize management of port tasks
  Improve configuration of process and port tables
  Remove R9 compatibility features
  Use ptab functionality also for ports
  Prepare for use of ptab functionality also for ports
  Atomic port state
  Generalize process table implementation
  Implement functionality for delaying thread progress from unmanaged threads

Conflicts:
	erts/doc/src/erl_driver.xml
	erts/doc/src/erlang.xml
	erts/emulator/beam/beam_bif_load.c
	erts/emulator/beam/beam_bp.c
	erts/emulator/beam/beam_emu.c
	erts/emulator/beam/bif.c
	erts/emulator/beam/copy.c
	erts/emulator/beam/erl_alloc.c
	erts/emulator/beam/erl_alloc.types
	erts/emulator/beam/erl_bif_info.c
	erts/emulator/beam/erl_bif_port.c
	erts/emulator/beam/erl_bif_trace.c
	erts/emulator/beam/erl_init.c
	erts/emulator/beam/erl_message.c
	erts/emulator/beam/erl_port_task.c
	erts/emulator/beam/erl_process.c
	erts/emulator/beam/erl_process.h
	erts/emulator/beam/erl_process_lock.c
	erts/emulator/beam/erl_trace.c
	erts/emulator/beam/export.h
	erts/emulator/beam/global.h
	erts/emulator/beam/io.c
	erts/emulator/sys/unix/sys.c
	erts/emulator/sys/vxworks/sys.c
	erts/emulator/test/port_SUITE.erl
	erts/etc/unix/cerl.src
	erts/preloaded/ebin/erlang.beam
	erts/preloaded/ebin/prim_inet.beam
	erts/preloaded/src/prim_inet.erl
	lib/hipe/cerl/erl_bif_types.erl
	lib/kernel/doc/src/inet.xml
	lib/kernel/src/inet.erl

1 files changed, 89 insertions, 0 deletions

diff --git a/erts/doc/src/communication.xml b/erts/doc/src/communication.xml
new file mode 100644
index 0000000000..6049123f6a
--- /dev/null
+++ b/erts/doc/src/communication.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE chapter SYSTEM "chapter.dtd">
+
+<chapter>
+  <header>
+    <copyright>
+      <year>2012</year><year>2012</year>
+      <holder>Ericsson AB. All Rights Reserved.</holder>
+    </copyright>
+    <legalnotice>
+      The contents of this file are subject to the Erlang Public License,
+      Version 1.1, (the "License"); you may not use this file except in
+      compliance with the License. You should have received a copy of the
+      Erlang Public License along with this software. If not, it can be
+      retrieved online at http://www.erlang.org/.
+
+      Software distributed under the License is distributed on an "AS IS"
+      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+      the License for the specific language governing rights and limitations
+      under the License.
+
+    </legalnotice>
+
+    <title>Communication in Erlang</title>
+    <prepared>Rickard Green</prepared>
+    <responsible></responsible>
+    <docno></docno>
+    <approved></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
+     signals. The most commonly used signal is a message. Other
+     common signals are exit, link, unlink, monitor, demonitor
+     signals.</p>
+  <section>
+    <title>Passing of Signals</title>
+    <p>The amount of time that passes between a signal being 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
+    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
+    an entity sends multiple signals to the same destination entity,
+    the order will be preserved. That is, if <c>A</c> send
+    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
+    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
+    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 behavior will always respect 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
+    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>
+    <list type="bulleted">
+      <item>As of ERTS version 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
+      are truly asynchronously delivered.</item>
+    </list>
+  </section>
+</chapter>
+