aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/doc
diff options
context:
space:
mode:
authorMagnus Henoch <[email protected]>2014-06-27 17:57:04 +0100
committerMagnus Henoch <[email protected]>2014-09-19 18:48:12 +0100
commit69e8387629bdea141e196c515f4d9381f7ac3e18 (patch)
treefb9843a0e7828942c289df7a689b64238c7f8338 /lib/stdlib/doc
parent6ec976bd70a657efea2d5d714e0d470aeb86bb50 (diff)
downloadotp-69e8387629bdea141e196c515f4d9381f7ac3e18.tar.gz
otp-69e8387629bdea141e196c515f4d9381f7ac3e18.tar.bz2
otp-69e8387629bdea141e196c515f4d9381f7ac3e18.zip
Optimise io requests for long message queues
Ensure that the monitor reference is present in all receive clauses, so that the compiler optimisation kicks in and the run time won't depend on the length of the message queue of the calling process. Remove the 'EXIT' clause, as its presence breaks the optimisation, and that case is handled by the 'DOWN' clause anyway. The test io_SUITE:io_with_huge_message_queue is an adaptation of gen_server_SUITE:call_with_huge_message_queue.
Diffstat (limited to 'lib/stdlib/doc')
-rw-r--r--lib/stdlib/doc/src/io_protocol.xml7
1 files changed, 4 insertions, 3 deletions
diff --git a/lib/stdlib/doc/src/io_protocol.xml b/lib/stdlib/doc/src/io_protocol.xml
index 9328704e11..d6da205f07 100644
--- a/lib/stdlib/doc/src/io_protocol.xml
+++ b/lib/stdlib/doc/src/io_protocol.xml
@@ -76,10 +76,11 @@ the server eventually sends a corresponding <c>io_reply</c> tuple.</p>
the I/O server sends the IO reply to.</item>
<item><c>ReplyAs</c> can be any datum and is returned in the corresponding
-<c>io_reply</c>. The <seealso marker="stdlib:io">io</seealso> module simply uses the pid()
-of the I/O server as the <c>ReplyAs</c> datum, but a more complicated client
+<c>io_reply</c>. The <seealso marker="stdlib:io">io</seealso> module monitors
+the I/O server, and uses the monitor reference as the <c>ReplyAs</c> datum.
+A more complicated client
could have several outstanding I/O requests to the same I/O server and
-would then use i.e. a <c>reference()</c> or something else to differentiate among
+would then use different references (or something else) to differentiate among
the incoming IO replies. The <c>ReplyAs</c> element should be considered
opaque by the I/O server. Note that the <c>pid()</c> of the I/O server is not
explicitly present in the <c>io_reply</c> tuple. The reply can be sent from any