Hi Arne
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.
As Igor has already pointed out, you don't have to use multiple threads. In fact, it's perfectly sensible to use multiple asynchronous_state_machine<> subclass objects hosted in one fifo_scheduler in a program that only has exactly one thread. Moreover, even under circumstances where you have very limited control over a global message queue and its handlers, you should still be able to use fifo_scheduler, as you can instruct it to simply return from its operator() as soon as its internal queue runs empty. So, in your scenario, if you can ensure that fifo_scheduler::operator() is called periodically, you *can* use async machines.
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().
state_machine<>::post_event() is not intended to be called from code "outside" of the machine, but only transition actions, which is why post_event is documented as being protected. Unfortunately, it is public in the code because it has to be called from other class templates and template friend support was very spotty at the time this was implemented. Anyway, I certainly could have done more to prevent calls from outside (e.g. with an assert and/or better documentation). May I ask you to enter a ticket for this? Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.