Subject: Re: [boost] [msm] Event deferring causes stack overflow
From: Richard Szabo (sz.richard_at_[hidden])
Date: 2010-11-09 17:21:37
Thanks for the quick response. I will use your suggestion with the
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
On 9 November 2010 22:35, Christophe Henry
>> 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.
> 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
> 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.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk