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, event3, 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.
Cheers Richie
Hi Richard, 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. Regards, Christophe