-
- If the state changes, is the initial state,
+ If
+
+ state enter calls
+
+ are used, and either:
+ the state changes, it is the initial state,
+ or one of the callback results
repeat_state
@@ -736,16 +747,21 @@ handle_event(_, _, State, Data) ->
repeat_state_and_data
- is used, and also
- state enter calls
- are used, the gen_statem calls
+ is 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.
+ appended to the actions
+ returned by the state callback that caused the state entry.
+
+
+ Should this state enter call return any of
+ the mentioned repeat_* callback results
+ it is repeated again, with the updated Data.
-
@@ -774,7 +790,7 @@ handle_event(_, _, State, Data) ->
All events stored with
action()
next_event
- are inserted to be processed before the other queued events.
+ are inserted to be processed before previously queued events.
-
@@ -788,7 +804,9 @@ handle_event(_, _, State, Data) ->
delivered to the state machine before any external
not yet received event so if there is such a time-out requested,
the corresponding time-out zero event is enqueued as
- the newest event.
+ the newest received event;
+ that is after already queued events
+ such as inserted and postponed events.
Any event cancels an
@@ -826,7 +844,7 @@ handle_event(_, _, State, Data) ->
When a new message arrives the
state callback
is called with the corresponding event,
- and we start again from the top of this list.
+ and we start again from the top of this sequence.
@@ -851,13 +869,19 @@ handle_event(_, _, State, Data) ->
@@ -892,7 +916,7 @@ handle_event(_, _, State, Data) ->
no timer is actually started,
instead the the time-out event is enqueued to ensure
that it gets processed before any not yet
- received external event.
+ received external event, but after already queued events.
Note that it is not possible nor needed to cancel this time-out,
@@ -978,7 +1002,9 @@ handle_event(_, _, State, Data) ->
If Abs is true an absolute timer is started,
and if it is false a relative, which is the default.
See
- erlang:start_timer/4
+
+ erlang:start_timer/4
+
for details.
@@ -1004,7 +1030,9 @@ handle_event(_, _, State, Data) ->
Actions that set
- transition options
+
+ transition options
+
override any previous of the same type,
so the last in the containing list wins.
For example, the last
@@ -1016,7 +1044,9 @@ handle_event(_, _, State, Data) ->
-
Sets the
- transition_option()
+
+ transition_option()
+
postpone()
for this state transition.
This action is ignored when returned from
@@ -1029,7 +1059,11 @@ handle_event(_, _, State, Data) ->
next_event
-
- Stores the specified EventType
+ This action does not set any
+
+ transition_option()
+
+ but instead stores the specified EventType
and EventContent for insertion after all
actions have been executed.
@@ -1101,15 +1135,15 @@ handle_event(_, _, State, Data) ->
transition options.
- Timeout
+ Time
-
- Short for {timeout,Timeout,Timeout}, that is,
+ Short for {timeout,Time,Time}, that is,
the time-out message is the time-out time.
This form exists to make the
state callback
- return value {next_state,NextState,NewData,Timeout}
- allowed like for gen_fsm's
+ return value {next_state,NextState,NewData,Time}
+ allowed like for gen_fsm.
timeout
@@ -1161,7 +1195,11 @@ handle_event(_, _, State, Data) ->
enter_loop/5,6.
- It replies to a caller waiting for a reply in
+ It does not set any
+
+ transition_option()
+
+ but instead replies to a caller waiting for a reply in
call/2.
From must be the term from argument
{call,From}
@@ -2144,16 +2182,20 @@ init(Args) -> erlang:error(not_implemented, [Args]).
You may also not change states from this call.
Should you return {next_state,NextState, ...}
with NextState =/= State the gen_statem crashes.
- It is possible to use {repeat_state, ...},
- {repeat_state_and_data,_} or
- repeat_state_and_data but all of them makes little
+ Note that it is actually allowed to use
+ {repeat_state, NewData, ...} although it makes little
sense since you immediately will be called again with a new
state enter call making this just a weird way
of looping, and there are better ways to loop in Erlang.
+ If you do not update NewData and have some
+ loop termination condition, or if you use
+ {repeat_state_and_data, _} or
+ repeat_state_and_data you have an infinite loop!
You are advised to use {keep_state,...},
{keep_state_and_data,_} or
- keep_state_and_data since you can not change states
- from a state enter call anyway.
+ keep_state_and_data
+ since changing states from a state enter call
+ is not possible anyway.
Note the fact that you can use
--
cgit v1.2.3