From 731cee0b06917f7b34b7e75700cb75605d7ebd32 Mon Sep 17 00:00:00 2001 From: Raimo Niskanen Date: Sun, 23 Oct 2016 20:46:49 +0200 Subject: Fix doc and type for state enter calls --- lib/stdlib/doc/src/gen_statem.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'lib/stdlib/doc/src/gen_statem.xml') diff --git a/lib/stdlib/doc/src/gen_statem.xml b/lib/stdlib/doc/src/gen_statem.xml index 64267c2af5..fb1e4e8da2 100644 --- a/lib/stdlib/doc/src/gen_statem.xml +++ b/lib/stdlib/doc/src/gen_statem.xml @@ -533,7 +533,7 @@ handle_event(_, _, State, Data) -> Type info originates from regular process messages sent to the gen_statem. Also, the state machine implementation can generate events of types - timeout, state_timeout, enter, + timeout, state_timeout, and internal to itself.

@@ -1773,7 +1773,7 @@ handle_event(_, _, State, Data) -> StateFunctionResult Module:handle_event(enter, OldState, State, Data) -> - StateEnterResult + StateEnterResult(State) Module:handle_event(EventType, EventContent, State, Data) -> HandleEventResult @@ -1802,8 +1802,8 @@ handle_event(_, _, State, Data) -> event_handler_result(state_name()) - StateEnterResult = - state_enter_result(state()) + StateEnterResult(State) = + state_enter_result(State) HandleEventResult = -- cgit v1.2.3 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/gen_statem.xml') 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 From 32485c0499a0893b4fb69c6e26d91b4303cb1cba Mon Sep 17 00:00:00 2001 From: Raimo Niskanen Date: Fri, 21 Oct 2016 23:36:26 +0200 Subject: Optimize event timeout Do not start an event timer unless there are no enqueued events. --- lib/stdlib/doc/src/gen_statem.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'lib/stdlib/doc/src/gen_statem.xml') diff --git a/lib/stdlib/doc/src/gen_statem.xml b/lib/stdlib/doc/src/gen_statem.xml index 567130875a..fd498ee82e 100644 --- a/lib/stdlib/doc/src/gen_statem.xml +++ b/lib/stdlib/doc/src/gen_statem.xml @@ -773,8 +773,9 @@ handle_event(_, _, State, Data) -> after this time (in milliseconds) unless another event arrives or has arrived in which case this time-out is cancelled. - Note that a retried, inserted or state time-out zero - events counts as arrived. + Note that a retried or inserted event counts as arrived. + So does a state time-out zero event, if it was generated + before this timer is requested.

If the value is infinity, no timer is started, as -- cgit v1.2.3