Re: [Boost-users] Boost MSM - Ways to send info out from state machine to outside world

Subject: Re: [Boost-users] Boost MSM - Ways to send info out from state machine to outside world
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-09-09 14:35:30

> Hi,
>
> I had one more question about the lifetime of the FSM. When does the state
> machine die? I was expecting that the state machine has to be explicitly
> killed (similar to fsm's start() method). But from whatever I have figured
> out, I think the state machine dies if it is in a state and no event 
> occurs.

No, what gave you this idea?
I'm afraid you're mixing 2 concepts. The lifecycle of a state machine is the 
same as any other class. Created on the stack, it is destroyed by stack 
unwinding, created on the heap, by delete.
The second concept is what is called run-to-completion. A state machine 
processes an event to the end (meaning, guard, exit, transition action, 
entry) then does nothing until another event is processed. True, there are 
state machine libraries running constantly in a thread, but this eats your 
cycles faster than a wolf a herd of sheeps and causes more race conditions 
than the upcoming Oktoberfest will produce drunken tourists sleeping on the 
pavement on my way home ;-)
So, no, msm does not do this.
The method start() is simply an optimization allowing you to delay the first 
call to on_entry until you really want it.

> If that is true, what will be an elegant way to "wait" inside a state till
> some event occurs (i.e. keeping FSM alive)?
> I came up with 2 ways:
>
> 1. Have following transition from the waiting state:
>    Row < state_waiting , none, state_waiting , none, none>
> and keep on calling process_event(none())
> This however causes the entering the state again and again and gives me
> segmentation fault ultimately.

Yes, stack overflow. Not something you want.

> 2. Have following transition:
>  Row < state_waiting, none, state_waiting, none, Gc_always_false>
> where guard condition Gc_always_false returns false, prohibiting the
> transition but still keeping the state machine alive.
>
> Can you please tell me if the 2nd option is correct and if there is a 
> better
> way to sit idle in one state and keep the machine alive.

If you want to keep your processor busy, sure, but I won't recommend it ;-)
Seriously, a state machine is event-triggered and does nothing until a next 
event is fired. It's a purely reactive system.
What are you trying to achieve?

HTH,
Christophe