fsm: Delaying dispatch of events while we're already inside a dispatch callback.

[Sylvain Munaut]

Hi,

So yeah, it definitely breaks stuff. Both because of those pointers
become invalid and also some code seems to rely on that order.
I pushed another version of the patch which just introduces a new
function with the "queue" semantics, but that might not be the right
approach to solve the initial problem.

So the initial issue is that once a RAN connection is first
established, it goes to the RAN_CONN_S_ACCEPTED state and starts a
timeout. Then when some messages are effectively exchanged,
"something" eventually calls ran_conn_communicating() and this
transitions the fsm to RAN_CONN_S_COMMUNICATING state (via sending a
RAN_CONN_E_COMMUNICATING event) and removed the timeout.

Now for a silent call, there might not be any message exchanged (since
we really have nothing to say) so the options are :

* Brute force approach is to hard code a bypass of the
RAN_CONN_S_ACCEPTED state directly to RAN_CONN_S_COMMUNICATING :

        case RAN_CONN_E_ACCEPTED:
                evaluate_acceptance_outcome(fi, true);
-               osmo_fsm_inst_state_chg(fi, RAN_CONN_S_ACCEPTED,
RAN_CONN_TIMEOUT, 0);
+               if (conn->silent_call)
+                       osmo_fsm_inst_state_chg(fi,
RAN_CONN_S_COMMUNICATING, 0, 0);
+               else
+                       osmo_fsm_inst_state_chg(fi,
RAN_CONN_S_ACCEPTED, RAN_CONN_TIMEOUT, 0);

  Personally not a big fan since you 'distribute' the knowledge of the
silent call around in other part of the code.

* Make it transition from ACCEPTED to COMMUNICATING from silent_call.c.
  To achieve this, what I first tried was to simply call
ran_conn_communicating() from the paging callback. Unfortunately that
doesn't work because if you lookat the current code :

        case RAN_CONN_E_ACCEPTED:
                evaluate_acceptance_outcome(fi, true);
               osmo_fsm_inst_state_chg(fi, RAN_CONN_S_ACCEPTED,
RAN_CONN_TIMEOUT, 0);

    the paging callback is called as part of
"evaluate_acceptance_outcome" and so this comes before the state is
changed to ACCEPTED. Deferring the dispatch of the event by changing
the FSM behavior was an attempt to fix this. (so the new
RAN_CONN_E_COMMUNICATING I generate would only be processed lates).

    But another option that also works is simply to swap the two calls
and change the FSM state first :

        case RAN_CONN_E_ACCEPTED:
               osmo_fsm_inst_state_chg(fi, RAN_CONN_S_ACCEPTED,
RAN_CONN_TIMEOUT, 0);
                evaluate_acceptance_outcome(fi, true);

    I checked and this also works fine.


Cheers,

     Sylvain





Cheers,

   Sylvain