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

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Sylvain Munaut 246tnt at gmail.com
Wed Feb 20 19:50:01 UTC 2019


Hi,

Currently if you call osmo_fsm_dispatch from a function that happens
to have been triggered by another call to dispatch, things can get a
little bit messy (depending on where that callback is in the chain of
even that may/may not change the state of the FSM).

So what I would propose is that any event dispatched to an FSM will be
processed only after the processing of any previous event is fully
completed (in the order they were generated). I have a prototype
implementation for review on gerrit :

https://gerrit.osmocom.org/c/libosmocore/+/12983

Now, this does break some tests, but looking at the breakage, it looks
just like message re-ordering at first glance. I guess running the
whole full range of test on this would be useful.

There are also another consequence is that it's now impossible to
return an error code if that event can't be handled in the current
state (previously dispatch would return -1). But since the actual
dispatch can be deferred ... well, can't do much. Looking at the
codebase, that error code is ignored most of the time. When it's
returned, it seems to always end up being ignored at the end of the
chain (because well ... realistically there isn't much you can do
about it anyway, it's a programming bug if it happens).

Thoughts / Comments ? Useful ? Crazy idea ? ...

Cheers,

    Sylvain



More information about the OpenBSC mailing list