diff options
| author | Magnus Henoch <[email protected]> | 2014-06-27 17:57:04 +0100 |
|---|---|---|
| committer | Magnus Henoch <[email protected]> | 2014-09-19 18:48:12 +0100 |
| commit | 69e8387629bdea141e196c515f4d9381f7ac3e18 (patch) | |
| tree | fb9843a0e7828942c289df7a689b64238c7f8338 /lib/stdlib/doc/src | |
| parent | 6ec976bd70a657efea2d5d714e0d470aeb86bb50 (diff) | |
| download | otp-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/src')
| -rw-r--r-- | lib/stdlib/doc/src/io_protocol.xml | 7 |
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 |