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