diff options
author | Neels Hofmeyr <neels@hofmeyr.de> | 2019-03-06 05:43:23 +0100 |
---|---|---|
committer | Neels Hofmeyr <neels@hofmeyr.de> | 2019-03-07 23:10:21 +0100 |
commit | d4b79c877291e58bf7fafcfd3c771c9e66fa3f5b (patch) | |
tree | 39a843fbb86e6d670aa3a49e77e0c505ae8efa28 /include/osmocom/core/tdef.h | |
parent | 4ea698233aa7f94e53a0bbf09e45506b216e32d4 (diff) |
fsm: add osmo_fsm_inst_state_chg_keep_or_start_timer()
During FSM design for osmo-msc, I noticed that the current behavior that
keep_timer=true doesn't guarantee a running timer can make FSM design a bit
complex, especially when using osmo_tdef for timeout definitions.
A desirable keep_timer=true behavior is one that keeps the previous timer
running, but starts a timer if no timer is running yet.
The simplest example is: a given state repeatedly transitions back to itself,
but wants to set a timeout only on first entering, avoiding to restart the
timeout on re-entering.
Another example is a repeated transition between two or more states, where the
first time we enter this group a timeout should start, but it should not
restart from scratch on every transition.
When using osmo_tdef timeout definitions for this, so far separate meaningless
states have to be introduced that merely set a fixed timeout.
To simplify, add osmo_fsm_inst_state_chg_keep_or_start_timer(), and use this in
osmo_tdef_fsm_inst_state_chg() when both keep_timer == true *and* T != 0.
In tdef_test.ok, the changes show that on first entering state L, the previous
T=1 is now kept with a large remaining timeout. When entering state L from O,
where no timer was running, this time L's T123 is started.
Change-Id: Id647511a4b18e0c4de0e66fb1f35dc9adb9177db
Diffstat (limited to 'include/osmocom/core/tdef.h')
0 files changed, 0 insertions, 0 deletions