In the MSM doc section "Enqueueing events for later processing", you state that "Calling execute_queued_events() will then process all enqueued events (in FIFO order)."
You also said in a previous post that MSM is not thread safe, thus requiring an external mechanism to insure thread safety.
True.
I don't see a mechanism to execute a single event at a time, which would be preferable if I have to lock the queue while processing events. Having said that, a cursory examination of the "execute_queued_events" code makes me think it only processes one event per call.
Looks like the implementation is wrong, I'll fix this and provide a second member for single event processing. May I ask what is your use case? Do you have a thread enqueuing events and another executing of several threads doing both? I ask because I'm working on C++11 MSMv3 (msm3 branch on github) and I have an unfinished but promising implementation of a lockfree msm which is much faster than locking. It works only on simple fsms at the moment (no submachine and no pseudo entry/exit). It works this way: all threads process events, call guards and actions concurrently. In case a thread notices at the time of switching the current state (which is only a check of an atomic), it will roll back and retry. It's a bit advanced fsm building but if you feel like trying, there are some tests showing how to do and I'm ready to help. I ask your use case because it works best when a thread processes most of the events and one only from time to time. HTH, Christophe