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 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 - step3, we just processed event4, do we have a deferred event? Yes, event3, try it again. - 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
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
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
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, ah, how could I miss this? There is a mistake in your LogDefer functor: typedef int deferring_action; This should be defined in the functor, not inside operator(). Then there will be no overflow. Cheers, Christophe PS: any news about your VC9 problem?
Hi Richard,
ah, how could I miss this? There is a mistake in your LogDefer functor: typedef int deferring_action;
Ah thanks for finding it ... I will try this out for you. In a mean time I have implemented our own event queue. But I will give a try to the original one ... it would be better to use that anyhow ... For the VC problem I had to time to play with it at all :( I found a one line change in the boost back end to solve my problem ..... I had to do this I was under high time pressure ..... even you disagree :(. line : if (!handled && !is_contained() && !is_completion_event<Event>::type::value) changed to : if ( ( handled == HANDLED_FALSE || handled == HANDLED_GUARD_REJECT) && !is_contained() && !is_completion_event<Event>::type::value) However I will prepare you a test project with the complexity/size similar to our current .... future size / complexity just for experiment and also give you a strip down version of our way of splitting the state machines maybe you can review it and give some ideas how to do thinks better :). But it takes some time to prepare this example and I have to check where are the limits of sharing our code base with open source community .... I personally would be happy to give all as it is but the company has different view about it I believe. I find MSM great I think it is easy to understand very expressive but the biggest downsize is the scalability in order to use it for our purpose, to write a complex communication protocol stack with a lot of events and state machines connected to each other. MSM is not usable as it is .... ( sorry to saying that It would hurt me if MSM would be my code ) we had to put in some effort to find an semi decent way of get around this problem ... So I think there is some work needs to be done in this area I'm happy to help as much as I can with it ... eg try to prepare an example project for experimenting .... So thanks for the help ... I will come back to you when I have something to play with but it will take some time ... hopefully it can be a christmas persent :). Thans for all the great support ... Cheers Richie
This should be defined in the functor, not inside operator(). Then there will be no overflow.
Cheers, Christophe
PS: any news about your VC9 problem?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Chistophe I have tried in the little example the change you have suggested : struct LogDefer { typedef int deferring_action; template <class EVT,class FSM,class SourceState,class TargetState> void operator()(EVT const& evt,FSM& fsm,SourceState& src_,TargetState& ) const { std::cout << fsm.m_SmName << " DEFERED: " << evt.getName() << std::endl; fsm.defer_event(evt); } }; but it did not help for me .... ?. :(. Sill stack overflow. Cheers Richie On 7 December 2011 12:30, Richard Szabo <sz.richard@googlemail.com> wrote:
Hi Richard,
ah, how could I miss this? There is a mistake in your LogDefer functor: typedef int deferring_action;
Ah thanks for finding it ... I will try this out for you. In a mean time I have implemented our own event queue. But I will give a try to the original one ... it would be better to use that anyhow ...
For the VC problem I had to time to play with it at all :( I found a one line change in the boost back end to solve my problem ..... I had to do this I was under high time pressure ..... even you disagree :(. line : if (!handled && !is_contained() && !is_completion_event<Event>::type::value) changed to : if ( ( handled == HANDLED_FALSE || handled == HANDLED_GUARD_REJECT) && !is_contained() && !is_completion_event<Event>::type::value)
However I will prepare you a test project with the complexity/size similar to our current .... future size / complexity just for experiment and also give you a strip down version of our way of splitting the state machines maybe you can review it and give some ideas how to do thinks better :). But it takes some time to prepare this example and I have to check where are the limits of sharing our code base with open source community .... I personally would be happy to give all as it is but the company has different view about it I believe.
I find MSM great I think it is easy to understand very expressive but the biggest downsize is the scalability in order to use it for our purpose, to write a complex communication protocol stack with a lot of events and state machines connected to each other. MSM is not usable as it is .... ( sorry to saying that It would hurt me if MSM would be my code ) we had to put in some effort to find an semi decent way of get around this problem ... So I think there is some work needs to be done in this area I'm happy to help as much as I can with it ... eg try to prepare an example project for experimenting ....
So thanks for the help ... I will come back to you when I have something to play with but it will take some time ... hopefully it can be a christmas persent :).
Thans for all the great support ...
Cheers Richie
This should be defined in the functor, not inside operator(). Then there will be no overflow.
Cheers, Christophe
PS: any news about your VC9 problem?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Chistophe
I have tried in the little example the change you have suggested :
struct LogDefer { typedef int deferring_action; template <class EVT,class FSM,class SourceState,class TargetState> void operator()(EVT const& evt,FSM& fsm,SourceState& src_,TargetState& ) const { std::cout << fsm.m_SmName << " DEFERED: " << evt.getName() << std::endl; fsm.defer_event(evt); } };
but it did not help for me .... ?. :(. Sill stack overflow.
Hi Richard, are you sure you didn't change anything else? I took your example and changed this line and it works fine (with trunk version, admittedly). I attach the code again. Tested with VC10. Cheers, Christophe
Hi Richard,
ah, how could I miss this? There is a mistake in your LogDefer functor: typedef int deferring_action;
Ah thanks for finding it ... I will try this out for you. In a mean time I have implemented our own event queue. But I will give a try to the original one ... it would be better to use that anyhow ...
Clearly ;-)
For the VC problem I had to time to play with it at all :( I found a one line change in the boost back end to solve my problem ..... I had to do this I was under high time pressure ..... even you disagree :(. line : if (!handled && !is_contained() && !is_completion_event<Event>::type::value) changed to : if ( ( handled == HANDLED_FALSE || handled == HANDLED_GUARD_REJECT) && !is_contained() && !is_completion_event<Event>::type::value)
Cutting corners under time pressure is ok I think. In the meantime we'll see how to make VC9 happy. And if not, I can still make a compile-time flag to get this behaviour so that you can keep working.
However I will prepare you a test project with the complexity/size similar to our current .... future size / complexity just for experiment and also give you a strip down version of our way of splitting the state machines maybe you can review it and give some ideas how to do thinks better :).
Sure.
But it takes some time to prepare this example and I have to check where are the limits of sharing our code base with open source community .... I personally would be happy to give all as it is but the company has different view about it I believe.
I think if you anonymize your state machine, it should be ok. If you wish, you can also send it to me privately.
I find MSM great I think it is easy to understand very expressive but the biggest downsize is the scalability in order to use it for our purpose, to write a complex communication protocol stack with a lot of events and state machines connected to each other.
Writing too big machines is like a big function, somehow, you get to pay for it. I write protocols with it by adding a fsm level on top of another etc. etc. By layering much, I manage to keep my fsms relatively small. But yes, MSM is demanding on compilers and VC9 is not the best out there.
MSM is not usable as it is .... ( sorry to saying that It would hurt me if MSM would be my code ) we had to put in some effort to find an semi decent way of get around this problem ... So I think there is some work needs to be done in this area I'm happy to help as much as I can with it ... eg try to prepare an example project for experimenting ....
It also remains to be seen how much VC9 has to do with the story. I wouldn't be surprised to seethat the compiler is the one to blame.
So thanks for the help ... I will come back to you when I have something to play with but it will take some time ... hopefully it can be a christmas persent :).
I'd prefer chocolates but ok, I'll do with it ;-)
Thans for all the great support ...
Welcome.
Cheers Richie
Regards, Christophe
participants (2)
-
Christophe Henry -
Richard Szabo