That's good to know - I did not realize that. From the tutorial and the reference I had the impression that a separate thread would be needed for every other state machine, and I also wanted to go the easy way first ;-) I'll give it a try; according to the reference all functionality I need seem to be available.
Ok, let me know if you have any trouble. Async machines differ quite a bit from sync ones.
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? Sure, the ticket is opened.
Thanks.
Regarding my other questions about the synchroneous state machine: is it really intended that a new event is processed before other events already queued? Of course this might be related to the post_event() issue above - if events cannot be queued up from outside without being processed immediately, the queue cannot contain any pending events. Right?
Correct, if post_event is only ever called from transition actions then the posted events are processed as the last step of process_event, so there cannot be any event ordering issues. Regards, Andreas