Re: [boost] [msm] Event deferring causes stack overflow
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
Hi Christophe Thanks for the quick response. I will use your suggestion with the deferred_events typedef. It is ok for us to use a typedef of an mpl::vector with deferred events in the sates. It is not that nice for 2 reasons: 1. It makes state machine behavior description more splinted in our case to several files ( not a big deal). 2. I have created our own defer functor which logs the event deferral with our logging framework is there a way do similar function in a state like the no_transition for deferred events where I can implement some generic logging ?. Br. Richie On 9 November 2010 22:35, Christophe Henry <christophe.j.henry@googlemail.com> wrote:
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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Christophe Henry -
Richard Szabo