Re: [boost] [msm] Event deferring causes stack overflow

Subject: Re: [boost] [msm] Event deferring causes stack overflow
From: Richard Szabo (sz.richard_at_[hidden])
Date: 2010-11-09 17:21:37

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_at_[hidden]> 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
>