Re: [boost] [MSM] feature request stop(const event& event_)

Subject: Re: [boost] [MSM] feature request stop(const event& event_)
From: Richard Szabo (sz.richard_at_[hidden])
Date: 2011-04-01 19:47:36

>> 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_at_[hidden]> 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
>