Hi All
We have found a serious problem in msm back end for event deferring. I case there is a composite state and the outer state machine defers 2 events when it is in the composite state, the 1st event deferred fine in the deferred queue of the outer state machine. Than the 2nd event is processed and this is deferred as well as a part of this deferral msm back end dispatches the 1st event but it is still deferred and saved again in the deferred queue but than msm processes the deferred queue again as an action of the deferral of the 1st event and dispatches the 2nd event again which is deferred and the cycle repeats itself until the system runs out of call stack.
Hi, No, it's not that serious, but still not nice. The problem is that the principle of the Defer functor is not working and I am wondering if I should keep it. To make short, Defer is an action, and for all front-ends, actions return void. This has the unintended effect of marking the transition results as "handled" instead of "deferred", which breaks my defensive measures. If you replace the transitions by the standard UML method of marking the state as deferring (through the deferred_events typedef), you have no more stack overflow. Now I understand that the Defer functor is cool and offering to remove it is guaranteed to cause disappointment, so I see 2 possibilities: - explaining its limitations in the doc - making a change to all front-ends for this special case to work around the fact that actions return void For the meantime, use the "normal" way and I will see if I find a workaround. Cheers, Christophe