[Boost-users] [Statechart] Question regarding state_machine event handling

Subject: [Boost-users] [Statechart] Question regarding state_machine event handling
From: Arne Babnik (boost_at_[hidden])
Date: 2010-02-25 10:07:34

Hi,

I'm currently working with the the statechart library in version 1.42.0 
and have some difficulties with the way the simple state_machine 
processes its events.
For my work I need several independent state machines, which communicate 
with each other using process_event/post_event.

For various reasons I do not want to use the asynchroneous_state_machine 
- mostly because my application is built around a global event/message 
handler and I do not want to use multiple threads with their necessary 
synchronization.
It basically works because in my hierarchy 
state_machine<>::process_event() is called only in one direction, while 
in the "opposite" direction (or if unsure) state_machine<>::post_event() 
is being used.
E.g. A calls B->process_event(), B calls C->process_event(), but C calls 
B->post_event() and B calls A->post_event().

This works so far, and since the process_event() function also processes 
events posted from within its execution context I do not see any 
problems with this.
However, what I could really make use of are two functions:
a) a query function to check if there are any events in the state 
machine queue (if additional post_event() calls have been made outside 
the process_event() context); and
b) a process_event() function that does not need an event argument, but 
only processes the queue. Currently I use a "dummy" event for this, but 
this is rather ugly.

Does anybody know why such functions are not available?
For b) there is a function named "process_queued_events()" that does 
exactly what I need, but unfortunately this function is declared 
private.For a), a simple "eventQueue_.empty()" wrapper would suffice.

An even bigger problem for me is that process_event() executes the event 
argument _first_. I'm rather used to state machines that process their 
events in-order regardless of the way they got queued up, so I had 
expected that process_event() first executes the events already in the 
queue before processing the given event (in other words, the given event 
argument is only put to the end of the queue initially, and then the 
queue is processed).
Any ideas why the state machine works this way? What is the rationale 
for this behaviour?

Thanks,
Arne