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 On 24 November 2011 23:02, Christophe Henry <christophe.j.henry@googlemail.com> wrote:
Hi Christophe
just playing around with event deferral I have found a problem which leads to a stack overflow it ends in an infinite loop if I want to defer 2 events in the same state.
see attached example it somehow similar to the problem we had earlier but that was fixed ...
I have ran this test on MSM trunk version from yesterday.
Cheers Richie
Hi Richard,
interesting case, I didn't think about it. It's not deferring any 2 events but these 2 events in this order which creates the overflow. - step 1, event3 is processed and deferred - step 2, event4 is processed and deferred - step4, event3 is deferred again, do we have more? Yes, event4 etc.
I need to think more about it, this one is hard.
Cheers, Christophe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost