Re: [Boost-users] [boost-users][StateChart]

From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2008-05-26 15:41:22

Hi Igor

> 1. IIUC, in async_state_machine it's impossible to post an "internal"
> event from a state by calling queue_event(), as noone will actually
> call process_event().

asynchronous_state_machine<>.queue_event() does not exist. IIUC, then you 
simply want to post an event, no? That is, at some point while an event is 
being processed (e.g. in an entry action, in a transition action, etc.) you 
want ensure that another event will be processed right after the machine is 
done with the current event? In that case, simply call 
simple_state.post_event(), please see

<http://www.boost.org/doc/libs/1_35_0/libs/statechart/doc/reference.html#post_event1>

> Instead, it should be always done through the
> processor queue, like this:
>  outermost_context_type &machine = outermost_context();
>  machine.my_scheduler().queue_event(machine.my_handle(), MyEvent());
> Am I right?

It depends. What you describe here ultimately has the same effect as calling 
simple_state<>.post_event(), with one crucial difference: In the first 
approach the posted event has absolute priority over events in the 
fifo_scheduler queue. In the second approach the event is put into the same 
queue as external events, with the effect that an event from the outside 
could be processed before event you queued from inside the machine. Usually 
(but not always) you want the first behavior.

> 2. Deferred events in async.machine. Say, we've got the following
> states (simplified code):
>
> struct State1 : simple_state<...>
> {
>  typedef transition<EvGotoState2,  State2> reactions;
> };
>
> struct State2 : simple_state<...>
> {
>  typedef mpl::list
>  <
>    transition<EvGotoState1,  State1>,
>    deferral<EvGotoState2>
>  >
>  reactions;
> };
>
> Both events are queued to the machine from the "outer world".
> * We're already in State2.
> * We get a bunch of EvGotoState2 posted (eg., 10 events). All of them
> are queued to the state's deferred events queue.
> * EvGotoState1 comes. The machine goes to State1 and then immediately
> consumes 1 deferred EvGotoState2 and move to State2. What happens to
> the rest of the deferred events? Are they queued again to the deferral
> queue of State2?

Yes.

> 3. Is it possible to clear all the deferred events?

Not explicitly.

> Is it possible to
> clear deferred events of a specific type? Eg., in State2 I'd like to
> alway defer only the *last* EvGotoState2, discarding all the previous
> deferred events of this type. Is it possible?

Not explicitly. Currently you'd have to use tricks to achieve such behavior.

HTH,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.