From 8efef4a2b75a7c7db54cb1b2d4b7ed36bba78db9 Mon Sep 17 00:00:00 2001
From: Raimo Niskanen <raimo@erlang.org>
Date: Fri, 6 Oct 2017 11:46:38 +0200
Subject: Change {clean_timeout,infinity} to use proxy

---
 lib/stdlib/doc/src/gen_statem.xml | 10 +++++++---
 lib/stdlib/src/gen_statem.erl     |  2 --
 2 files changed, 7 insertions(+), 5 deletions(-)

(limited to 'lib/stdlib')

diff --git a/lib/stdlib/doc/src/gen_statem.xml b/lib/stdlib/doc/src/gen_statem.xml
index 8de6ed754f..4a824f073e 100644
--- a/lib/stdlib/doc/src/gen_statem.xml
+++ b/lib/stdlib/doc/src/gen_statem.xml
@@ -1329,7 +1329,7 @@ handle_event(_, _, State, Data) ->
 	  <c><anno>T</anno></c> is the time-out time.
 	  <c>{clean_timeout,<anno>T</anno>}</c> works like
 	  just <c>T</c> described in the note above
-	  and uses a proxy process for <c>T &lt; infinity</c>,
+	  and uses a proxy process
 	  while <c>{dirty_timeout,<anno>T</anno>}</c>
 	  bypasses the proxy process which is more lightweight.
 	</p>
@@ -1339,8 +1339,12 @@ handle_event(_, _, State, Data) ->
 	    with <c>{dirty_timeout,<anno>T</anno>}</c>
 	    to avoid that the calling process dies when the call
 	    times out, you will have to be prepared to handle
-	    a late reply.
-	    So why not just let the calling process die?
+	    a late reply.  Note that there is an odd chance
+	    to get a late reply even with
+	    <c>{dirty_timeout,infinity}</c> or <c>infinity</c>
+	    for example in the event of network problems.
+	    So why not just let the calling process die
+	    by not catching the exception?
 	  </p>
 	</note>
 	<p>
diff --git a/lib/stdlib/src/gen_statem.erl b/lib/stdlib/src/gen_statem.erl
index 1110d18af6..98979c6627 100644
--- a/lib/stdlib/src/gen_statem.erl
+++ b/lib/stdlib/src/gen_statem.erl
@@ -510,8 +510,6 @@ call(ServerRef, Request, Timeout) ->
 
 parse_timeout(Timeout) ->
     case Timeout of
-	{clean_timeout,infinity} ->
-	    {dirty_timeout,infinity};
 	{clean_timeout,_} ->
 	    Timeout;
 	{dirty_timeout,_} ->
-- 
cgit v1.2.3