From f986565050ac30075ef3c0a451bf6dad91c7c446 Mon Sep 17 00:00:00 2001
From: Raimo Niskanen
Date: Tue, 13 Sep 2016 11:15:32 +0200
Subject: Implement call/3 dirty_timeout
---
lib/stdlib/doc/src/gen_statem.xml | 32 +++++++++++++++++++++++++++-----
1 file changed, 27 insertions(+), 5 deletions(-)
(limited to 'lib/stdlib/doc/src')
diff --git a/lib/stdlib/doc/src/gen_statem.xml b/lib/stdlib/doc/src/gen_statem.xml
index 3322571b2c..17f1526a21 100644
--- a/lib/stdlib/doc/src/gen_statem.xml
+++ b/lib/stdlib/doc/src/gen_statem.xml
@@ -919,18 +919,40 @@ handle_event(_, _, State, Data) ->
- For Timeout =/= infinity,
+ For Timeout < infinity,
to avoid getting a late reply in the caller's
- inbox, this function spawns a proxy process that
+ inbox if the caller should catch exceptions,
+ this function spawns a proxy process that
does the call. A late reply gets delivered to the
dead proxy process, hence gets discarded. This is
less efficient than using
- Timeout =:= infinity.
+ Timeout == infinity.
- The call can fail, for example, if the gen_statem dies
- before or during this function call.
+ Timeout can also be a tuple
+ {clean_timeout,T} or
+ {dirty_timeout,T}, where
+ T is the timeout time.
+ {clean_timeout,T} works like
+ just T described in the note above
+ and uses a proxy process for T < infinity,
+ while {dirty_timeout,T}
+ bypasses the proxy process which is more lightweight.
+
+
+
+ If you combine catching exceptions from this function
+ with {dirty_timeout,T}
+ 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 allow the calling process to die?
+
+
+
+ The call can also fail, for example, if the gen_statem
+ dies before or during this function call.
--
cgit v1.2.3