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

[Harald Welte]

Hi Sylvain,

On Wed, Feb 20, 2019 at 08:50:01PM +0100, Sylvain Munaut wrote:
> 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).

Yes, it's not particularly elegant in all cases, but it fits our synchronous
architecture, where we are used to processing one packet (that may become an
event) in one go.

> 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 :

This will break all use cases where the "data" pointer of an event is something
allocated on the stack by the caller, or where it is a msgb or other object
that simply may no longer exist at the time the deferred event is being processed.

Or am I missing something?

So while I trust there are use cases where your proposed behavior is useful,
we must not change the existing semantics.  We could introduce a new
"dispatch_event_deferred()" or something like that which exhibits the new
properties, while the existing API semantics remain unmodified.
Would that help you?

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)