Subject: Re: [boost] [msm] deferral stack overfolw
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-11-28 15:45:37
> Hi Christophe
> I don't really see the reason of this in your logic
>> - step3, we just processed event4, do we have a deferred event? Yes,
>> try it again.
> I think evaluation of deferred events has to be done when the state
> has changed and not at each event processing.
> the event shall be staying deferred as long as the state / states are
> the same and shall be reprocessed after a state change.
> so for me :
> - step3, we just processed event4, is state changed and do we have a
> deferred event? No, event3, stays in deferred queue.
> This would solve the problem from my other example as well.
Yes but then some constructs deferring using a transition with Defer and a
guard will deliver some suprising effect like not being called again though
the guard would allow it at say, the 3rd try. Admittedly, this would be a
quite unlikely construct so it could be ignored for the moment (the stack
overflow is clearly worse).
I'll have a look at it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk