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

Subject: Re: [boost] [msm] Event deferring causes stack overflow
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2010-11-09 16:35:12

> 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