From 0b4deedf278273205c9dcd2ed5d0b4b4d4d8fb9d Mon Sep 17 00:00:00 2001
From: Raimo Niskanen
Date: Thu, 20 Oct 2016 22:28:10 +0200
Subject: Rework timeout handling
Handling of timers and timeouts has been cleaned up
and generalized.
Semantic change regarding state timeout zero:
Previously if one state caused a state timeout zero and
managed to stay in the same state to insert additional
timeout zero(s) in the next state callback invocation, then
there would be only one timeout zero event. The mindset
was that the machine was faster then the timeout zero.
This has changed with the mindset that all state callback
invocations should be independent, so now the machine will
get one state timeout zero event per started state timeout
zero.
Note that just using zero timeouts is fairly esoteric...
---
lib/stdlib/doc/src/gen_statem.xml | 66 ++++++++++++++++++++++++---------------
1 file changed, 40 insertions(+), 26 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 fb1e4e8da2..567130875a 100644
--- a/lib/stdlib/doc/src/gen_statem.xml
+++ b/lib/stdlib/doc/src/gen_statem.xml
@@ -638,6 +638,20 @@ handle_event(_, _, State, Data) ->
and they modify how the state transition is done:
+ -
+
+ If the state changes or is the initial state, and
+ state enter calls
+ are used, the gen_statem calls
+ the new state callback with arguments
+ (enter, OldState, Data).
+ Any
+ actions
+ returned from this call are handled as if they were
+ appended to the actions
+ returned by the state callback that changed states.
+
+
-
All
@@ -667,37 +681,37 @@ handle_event(_, _, State, Data) ->
are inserted to be processed before the other queued events.
- -
-
- If the state changes or is the initial state, and
- state enter calls
- are used, the gen_statem calls
- the new state callback with arguments
- (enter, OldState, Data).
- Any
- actions
- returned from this call are handled as if they were
- appended to the actions
- returned by the state callback that changed states.
-
-
- -
-
- If there are enqueued events the (possibly new)
- state callback
- is called with the oldest enqueued event,
- and we start again from the top of this list.
-
-
-
Timeout timers
state_timeout()
and
event_timeout()
- are handled. This may lead to a time-out zero event
- being generated to the
+ are handled. Time-outs with zero time are guaranteed to be
+ delivered to the state machine before any external
+ not yet received event so if there is such a timeout requested,
+ the corresponding time-out zero event is enqueued as
+ the newest event.
+
+
+ Any event cancels an
+ event_timeout()
+ so a zero time event time-out is only generated
+ if the event queue is empty.
+
+
+ A state change cancels a
+ state_timeout()
+ and any new transition option of this type
+ belongs to the new state.
+
+
+ -
+
+ If there are enqueued events the
state callback
+ for the possibly new state
+ is called with the oldest enqueued event,
and we start again from the top of this list.
@@ -802,7 +816,7 @@ handle_event(_, _, State, Data) ->
Setting this timer while it is running will restart it with
the new time-out value. Therefore it is possible to cancel
- this timeout by setting it to infinity.
+ this time-out by setting it to infinity.
@@ -1130,7 +1144,7 @@ handle_event(_, _, State, Data) ->
Timeout can also be a tuple
{clean_timeout,T} or
{dirty_timeout,T}, where
- T is the timeout time.
+ T is the time-out time.
{clean_timeout,T} works like
just T described in the note above
and uses a proxy process for T < infinity,
--
cgit v1.2.3