Re: [boost] [MSM] Interrupt anonymous transitions or blocking process_events?

Subject: Re: [boost] [MSM] Interrupt anonymous transitions or blocking process_events?
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-04-16 10:18:11

Hi Mathias,

<snip>

>By calling p.process_event(play()); the the player will start playing
>Song1 and then change to the next song by itself. But now in single
>threaded mode it blocks until it reaches "Song3". So it is not possible
>to process any other events during this time. In other words, it cannot
>process another process_event call. The "Playing" state has a "stop"
>event but calling this will not help as it will not be processed until
>the MSM has reached "Song3".

The problem is that a state machine is based on run-to-completion.
This means in your case that a transition must be "short". An event
comes, a transition is executed, the state machine is in a new stable
state and can process a new event. Until this happens, events are
queued (in the case of MSM).

>I start the same p.process_event(play()); in thread 1. And in thread 2 I
>call p.process_event(stop()); The problem with this is that the stop()
>event does not get processed until it reaches Song3 because of the
>blocking call in p.process_event(play());.

Actually I'd think because of the mutex. In any case, your design will
be hard to get right I'm afraid.

>Perhaps I am going about this the wrong here and please tell me if it
>can be done in some other much better way! I want to be able to have
>automatic transitions that I can interrupt.

You have to use run-to-completion. Base your design on short-terms
events fed to the state machine, which triggers work and reacts to
changes in forms of other events.
In your case, one possibility would be to have the state machine
delegate (post) some work upon state entry or transition action to a
thread, then posting a new task upon state exit, etc.
Make your state machine be serviced by only one thread, triggering
work and reacting to events. Trust me on that one, having a state
machine serviced by 2 threads is a good receipt for headaches ;-)
If you know boost::asio, it's a bit like the async_xxx methods,
trigger some work and get ready for the next action (which would be a
callback, to continue with this asio example).

HTH,
Christophe