From 69e8387629bdea141e196c515f4d9381f7ac3e18 Mon Sep 17 00:00:00 2001 From: Magnus Henoch Date: Fri, 27 Jun 2014 17:57:04 +0100 Subject: 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. --- lib/stdlib/doc/src/io_protocol.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'lib/stdlib/doc') 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 io_reply tuple.

the I/O server sends the IO reply to. ReplyAs can be any datum and is returned in the corresponding -io_reply. The io module simply uses the pid() -of the I/O server as the ReplyAs datum, but a more complicated client +io_reply. The io module monitors +the I/O server, and uses the monitor reference as the ReplyAs 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 reference() or something else to differentiate among +would then use different references (or something else) to differentiate among the incoming IO replies. The ReplyAs element should be considered opaque by the I/O server. Note that the pid() of the I/O server is not explicitly present in the io_reply tuple. The reply can be sent from any -- cgit v1.2.3