Bug #2915
closed
FSM: Do not terminate child FSMs early
Added by dexter about 6 years ago.
Updated about 6 years ago.
Description
When an FSM is terminated _osmo_fsm_inst_term() first terminates the child FSMs and then executes the cleanup callback of the respective FSM. This prevents the FSM to perform actions on its children while it is terminated. Eventually this behavior prevents a graceful exit of the child FSMs. The parent FSM should always be able to signal last actions to its child FSMs before the final termination happens.
The patch that got merged recently caused unexpected fallout on the unit-tests of osmo-msc and had to be reverted:
https://gerrit.osmocom.org/6318
Manual tests on the test-network (includes osmo-bsc, osmo-msc, osmo-hlr, osmo-stp and osmo-mgw) did not reveal any behavioral difference. Also the TTCN3 testsuit for the BSC did not show any sign of problems caused by the patch. However, the fallout needs to be investigated and we need to check if it actually changes behavior or or if it just changes the position of some log-lines (expected, cleanup_cb now runs before the child termination).
Attached one finds a patch that shows the difference of the changed log-output of the test (.err).
Files
Also checked (just to be sure) the unit-tests of:
osmo-iuh
osmo-sgsn
libosmo-netif
osmo-bsc
libosmo-sccp
osmo-hlr
No problems detected there so far.
- Status changed from New to In Progress
- % Done changed from 0 to 100
I have analyzed the problem further, even when the change seems not to cause any harm to osmo-msc, osmo-stp and other users of OSMO-FSM we should opt against the patch since it drastically changes the behavior on how OSMO-FSMs are terminated.
The FSM childs are freed first on a termination. This models a recursion where the cleanup callbacks run from the leaf child to the parent. The call traverses recursively to the very end of the FSM tree and starts terminating everything from the back. When the last child is terminated the call returns, to the above child until it arrives at the parent FSM. I assume that this is a well thought out paradigm of OSMO-FSM and should not be changed.
When we move the callback that terminates the childs after the cleanup callback. Then the first cleanup callback that runs is the one of the child next to the parent. From there the calls traverse down to the end until they reach the leaf child. So the direction changes to the opposite.
My idea to come around this is to introduce a grace (graceful exit) callback that runs on the beginning of each termination before the termination even starts.
See also: https://gerrit.osmocom.org/#/c/6452/
Hi Philipp,
On Wed, Feb 14, 2018 at 05:47:48PM +0000, dexter [REDMINE] wrote:
The FSM childs are freed first on a termination. This models a recursion where the cleanup callbacks run from the leaf child to the parent. The call traverses recursively to the very end of the FSM tree and starts terminating everything from the back. When the last child is terminated the call returns, to the above child until it arrives at the parent FSM. I assume that this is a well thought out paradigm of OSMO-FSM and should not be changed.
you give me more credit than I think I deserve ;) not sure if I had that
specifically in mind when designing the osmo_fsm code, or whether it was
simply the "natural, intuitive choice". But yes, I agree with your
analysis and I think it should be preserved.
- Status changed from In Progress to Resolved
Also available in: Atom
PDF
