Re: [boost] [MSM] feature request stop(const event& event_)
Hi Christophe and all
Now I have to put some effort to residing out code using MSM because one of our module where we use MSM has reached it's limits and we won't be able to compile it any more with VC9 32 bit compiler. In our implementation we have several sub state machines (around 20 per main state machine instance at the moment) ( nested in 4 level deep) and over time as we extend the functionality we introduce new sub state machines which are covering new functionality ...
We now can not add any more new sub state machines because we can not compile any more :(.
While big improvements were made, there will always be a limit, especially with VC9. Did you try with VC10? It'd be interesting to know.
So I have decided to split the big state machines with a lot of subs state machines to stand alone small state machine instances and use our dispatching framework to dispatch events between them. This way I will get small compile units.
Sounds good.
I'm managed to complete a job apart form one problem I have now. I'm not able to generally trigger the exit functions on the current active states of a state machine when it is finished it's execution like when a sub state machine exists to the outer state machine.
If you mean in the fsm destructor, it's true. I'd be surprised though if on_exit was not called when leaving a submachine to its outer.
Is it possible to implement something like stop method on the back end which would call exit on each region current state and than an exit of the state machine whit an event passed as an argument. ?
this would help me a lot and it would be similar to the start.
Ah yes I remember thinking about it in the early phase of MSM. Unfortunately I don't remember why it was not done, just that I had a reason at that time. Actually I think it'd be even better to automatically call on_exit in the destructor. The start method is there only because you might not want to start a state machine immediately upon creation, but I have never had a very good feeling about it, so I'd prefer not repeating this. Is there a reason why you want a stop method or the calls of on_exit inside the destructor would suffice (provided I don't hit again the issue I mentioned above)?
other minor thing is it possible to make public this version of start methode in the back_end ?
template <class Event> void start(Event const& incomingEvent)
I'm not sure you'd be happy with this because on_entry is not called in this version (it's meant to be called from the outer machine, which itself calls on_entry), so you'd have to call it yourself. What are you trying to achieve? Regards, Christophe
Br. Richard
Hi Christophe and all
Now I have to put some effort to residing out code using MSM because one of our module where we use MSM has reached it's limits and we won't be able to compile it any more with VC9 32 bit compiler. In our implementation we have several sub state machines (around 20 per main state machine instance at the moment) ( nested in 4 level deep) and over time as we extend the functionality we introduce new sub state machines which are covering new functionality ...
We now can not add any more new sub state machines because we can not compile any more :(.
While big improvements were made, there will always be a limit, especially with VC9. Did you try with VC10? It'd be interesting to know.
I will try this for you when I will have a spare 10 minutes. I did use for some time VC10 in the past and I did not observe too much difference in the heap usage during compilation.
So I have decided to split the big state machines with a lot of subs state machines to stand alone small state machine instances and use our dispatching framework to dispatch events between them. This way I will get small compile units.
Sounds good.
I'm managed to complete a job apart form one problem I have now. I'm not able to generally trigger the exit functions on the current active states of a state machine when it is finished it's execution like when a sub state machine exists to the outer state machine.
If you mean in the fsm destructor, it's true. I'd be surprised though if on_exit was not called when leaving a submachine to its outer.
Is it possible to implement something like stop method on the back end which would call exit on each region current state and than an exit of the state machine whit an event passed as an argument. ?
this would help me a lot and it would be similar to the start.
Ah yes I remember thinking about it in the early phase of MSM. Unfortunately I don't remember why it was not done, just that I had a reason at that time. Actually I think it'd be even better to automatically call on_exit in the destructor. The start method is there only because you might not want to start a state machine immediately upon creation, but I have never had a very good feeling about it, so I'd prefer not repeating this. Is there a reason why you want a stop method or the calls of on_exit inside the destructor would suffice (provided I don't hit again the issue I mentioned above)?
For exactly the same reason as you mentioned for the start. I don't necessarily want to destruct the SM when I want to leave all region and trigger all on_exit ( for all active state and than the main one). And put the state machine in to exactly same "state" as it was after construction before calling the start on it. I just would like to keep the SM and able to trigger the start again. which would bring back the state machine to the initial state. I think it is a quite useful feature to have construction destruction and start and stop separated. It gives to the user an option to "reset" (leave and than enter again) a state machine without potentially costly construction/destruction. Calling stop and than start would bring the state machine in to a known state in a predictable way. basically I would like achieve that 2 state machine communicates over signals achieving the same as one of them would be a composite state machine to the other. It is possible to enter and leave composite state machine several times without deleting it. with a sand alone state machine it is not possible. With a start is is almost posible to achieve the same behavior as an enter to a substate machine but there are no way at the moment to have similar action sequence on a stand alone SM as leaving a composite SM.
other minor thing is it possible to make public this version of start methode in the back_end ?
template <class Event> void start(Event const& incomingEvent)
I'm not sure you'd be happy with this because on_entry is not called in this version (it's meant to be called from the outer machine, which itself calls on_entry), so you'd have to call it yourself. What are you trying to achieve?
The public start has a limitation that I can't tell during runtime what event is triggering the start e.g I can't specify the initial event in runtime for the initial transitions. I want to use start to cause the same behavior as an entry transaction causes on a composite state machine. And yes I have figured out that the non public start does not calls the main on_entry I call it beforehand explicitly. Br. Richard On 1 April 2011 20:52, Christophe Henry <christophe.j.henry@googlemail.com> wrote:
Hi Christophe and all
Now I have to put some effort to residing out code using MSM because one of our module where we use MSM has reached it's limits and we won't be able to compile it any more with VC9 32 bit compiler. In our implementation we have several sub state machines (around 20 per main state machine instance at the moment) ( nested in 4 level deep) and over time as we extend the functionality we introduce new sub state machines which are covering new functionality ...
We now can not add any more new sub state machines because we can not compile any more :(.
While big improvements were made, there will always be a limit, especially with VC9. Did you try with VC10? It'd be interesting to know.
So I have decided to split the big state machines with a lot of subs state machines to stand alone small state machine instances and use our dispatching framework to dispatch events between them. This way I will get small compile units.
Sounds good.
I'm managed to complete a job apart form one problem I have now. I'm not able to generally trigger the exit functions on the current active states of a state machine when it is finished it's execution like when a sub state machine exists to the outer state machine.
If you mean in the fsm destructor, it's true. I'd be surprised though if on_exit was not called when leaving a submachine to its outer.
Is it possible to implement something like stop method on the back end which would call exit on each region current state and than an exit of the state machine whit an event passed as an argument. ?
this would help me a lot and it would be similar to the start.
Ah yes I remember thinking about it in the early phase of MSM. Unfortunately I don't remember why it was not done, just that I had a reason at that time. Actually I think it'd be even better to automatically call on_exit in the destructor. The start method is there only because you might not want to start a state machine immediately upon creation, but I have never had a very good feeling about it, so I'd prefer not repeating this. Is there a reason why you want a stop method or the calls of on_exit inside the destructor would suffice (provided I don't hit again the issue I mentioned above)?
other minor thing is it possible to make public this version of start methode in the back_end ?
template <class Event> void start(Event const& incomingEvent)
I'm not sure you'd be happy with this because on_entry is not called in this version (it's meant to be called from the outer machine, which itself calls on_entry), so you'd have to call it yourself. What are you trying to achieve?
Regards, Christophe
Br. Richard
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Christophe Henry -
Richard Szabo