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

* rickard/r16/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

3 files changed, 27 insertions, 24 deletions

diff --git a/system/doc/efficiency_guide/advanced.xml b/system/doc/efficiency_guide/advanced.xml
index 821175bb09..ac35a37bc4 100644
--- a/system/doc/efficiency_guide/advanced.xml
+++ b/system/doc/efficiency_guide/advanced.xml
@@ -123,12 +123,11 @@ On 64-bit architectures: 4 words for a reference from the current local node, an
       <tag><em>Processes</em></tag>
       <item>
         <p>The maximum number of simultaneously alive Erlang processes is
-          by default 32768. This limit can be raised up to at most 268435456
-          processes at startup (see documentation of the system flag
-          <seealso marker="erts:erl#max_processes">+P</seealso> in the
-          <seealso marker="erts:erl">erl(1)</seealso> documentation).
-          The maximum limit of 268435456 processes will at least on a 32-bit
-          architecture be impossible to reach due to memory shortage.</p>
+          by default 32768. This limit can be configured at startup,
+	  for more information see the
+	  <seealso marker="erts:erl#max_processes"><c>+P</c></seealso>
+	  command line flag of
+	  <seealso marker="erts:erl"><c>erl(1)</c></seealso>.</p>
       </item>
       <tag><em>Distributed nodes</em></tag>
       <item>
@@ -184,13 +183,12 @@ On 64-bit architectures: 4 words for a reference from the current local node, an
       <tag><em>Open ports</em></tag>
       <item>
         <marker id="ports"></marker>
-        <p>The maximum number of simultaneously open Erlang ports is
-          by default 1024. This limit can be raised up to at most 268435456
-          at startup (see environment variable
-          <seealso marker="erts:erlang#ERL_MAX_PORTS">ERL_MAX_PORTS</seealso>
-          in <seealso marker="erts:erlang">erlang(3)</seealso>)
-          The maximum limit of 268435456 open ports will at least on a 32-bit
-          architecture be impossible to reach due to memory shortage.</p>
+	  <p>The maximum number of simultaneously oper Erlang ports is
+	  often by default 16384. This limit can be configured at startup,
+	  for more information see the
+	  <seealso marker="erts:erl#max_ports"><c>+Q</c></seealso>
+	  command line flag of
+	  <seealso marker="erts:erl"><c>erl(1)</c></seealso>.</p>
       </item>
       <tag><em>Open files, and sockets</em></tag>
       <item>      <marker id="files_sockets"></marker>
diff --git a/system/doc/efficiency_guide/drivers.xml b/system/doc/efficiency_guide/drivers.xml
index fec68ca059..b10595ea4d 100644
--- a/system/doc/efficiency_guide/drivers.xml
+++ b/system/doc/efficiency_guide/drivers.xml
@@ -105,9 +105,9 @@ client_port() ->
     <p>If you know that the binaries you return are always small,
     you should use driver API calls that do not require a pre-allocated
     binary, for instance
-    <seealso marker="erts:erl_driver#int driver_output-3">driver_output()</seealso>
+    <seealso marker="erts:erl_driver#driver_output">driver_output()</seealso>
     or 
-    <seealso marker="erts:erl_driver#int driver_output_term-3">driver_output_term()</seealso>
+    <seealso marker="erts:erl_driver#erl_drv_output_term">erl_drv_output_term()</seealso>
     using the <c>ERL_DRV_BUF2BINARY</c> format,
     to allow the run-time to construct a heap binary.</p>
 
@@ -120,7 +120,7 @@ client_port() ->
     the driver to an Erlang process, the driver must first allocate the
     binary and then send it to an Erlang process in some way.</p>
     
-    <p>Use <seealso marker="erts:erl_driver#ErlDrvBinary* driver_alloc_binary-1">driver_alloc_binary()</seealso> to allocate a binary.</p>
+    <p>Use <seealso marker="erts:erl_driver#driver_alloc_binary">driver_alloc_binary()</seealso> to allocate a binary.</p>
 
     <p>There are several ways to send a binary created with
     <c>driver_alloc_binary()</c>.</p>
@@ -128,17 +128,17 @@ client_port() ->
     <list type="bulleted">
     <item><p>From the <c>control</c> callback, a binary can be returned provided
         that
-	<seealso marker="erts:erl_driver#void set_port_control_flags-2">set_port_control()</seealso>
+	<seealso marker="erts:erl_driver#set_port_control_flags">set_port_control_flags()</seealso>
 	 has been called with the flag value <c>PORT_CONTROL_FLAG_BINARY</c>.</p>
     </item>
 
     <item><p>A single binary can be sent with
-    <seealso marker="erts:erl_driver#int driver_output_binary-6">driver_output_binary()</seealso>.</p></item>
+    <seealso marker="erts:erl_driver#driver_output_binary">driver_output_binary()</seealso>.</p></item>
 
     <item><p>Using
-    <seealso marker="erts:erl_driver#int driver_output_term-3">driver_output_term()</seealso>
+    <seealso marker="erts:erl_driver#erl_drv_output_term">erl_drv_output_term()</seealso>
     or
-    <seealso marker="erts:erl_driver#int driver_send_term-4">driver_send_term()</seealso>,
+    <seealso marker="erts:erl_driver#erl_drv_send_term">erl_drv_send_term()</seealso>,
     a binary can be included in an Erlang term.</p>
     </item>
     </list>
diff --git a/system/doc/reference_manual/ports.xml b/system/doc/reference_manual/ports.xml
index 4847dd67cd..c4e4ef1d35 100644
--- a/system/doc/reference_manual/ports.xml
+++ b/system/doc/reference_manual/ports.xml
@@ -87,8 +87,14 @@
       of bytes, the option <c>binary</c> must be included.</p>
     <p>The port owner <c>Pid</c> can communicate with the port
       <c>Port</c> by sending and receiving messages. (In fact, any
-      process can send the messages to the port, but the messages from
-      the port always go to the port owner).</p>
+      process can send the messages to the port, but the port owner must
+      be identified in the message).</p>
+    <p>As of OTP-R16 messages sent to ports are delivered truly
+      asynchronously. The underlying implementation previously
+      delivered messages to ports synchronously. Message passing has
+      however always been documented as an asynchronous operation, so
+      this should not be an issue for an Erlang program communicating
+      with ports, unless false assumptions about ports has been made.</p>
     <p>Below, <c>Data</c> must be an I/O list. An I/O list is a binary
       or a (possibly deep) list of binaries or integers in the range
       0..255.</p>
@@ -127,8 +133,7 @@
       <tcaption>Messages Received From a Port.</tcaption>
     </table>
     <p>Instead of sending and receiving messages, there are also a
-      number of BIFs that can be used. These can be called by any
-      process, not only the port owner.</p>
+      number of BIFs that can be used.</p>
     <table>
       <row>
         <cell align="left" valign="middle"><c>port_command(Port,Data)</c></cell>