How are managed the events in QStateMachine?

Question

I work with a state machine based on QScxmlStateMachine . Some transitions are automatically triggered by code in the onEntry handlers, some others are triggered by external events (such as user click).

The execution of the state machine is asynchronous. This code is not blocking :

m_statemachine->submitEvent("user_initialize", settings);

Fine. What I want to know is how the processing inside the state machine is done then.
This first event is queued and will asynchronously enter in a state initializing , what about the events that could be triggered in this state onEntry code, are they queued too ?
Does the internal event-loop could process some other GUI events before processing the next transition ?
And, I assume not, is the state-machine event-loop in a separate thread ?

Answer 1

This first event is queued and will asynchronously enter in a state initializing, what about the events that could be triggered in this state onEntry code, are they queued too ?

All events are queued. The Qt term for these is posted events (as opposed to sent events that execute immediately).

And, I assume not, is the state-machine event-loop in a separate thread ?

The "internal" event loop is a bit of a misnomer. The state machine really runs on the current thread's event loop, but it copies some of the events and processes them later.

Does the internal event-loop could process some other GUI events before processing the next transition?

Yes. You're only guaranteed the relative event processing order within the state machine itself. Any number of events could be processed between each event delivered to the state machine. That's always the case no matter what sort of event processing you're doing. The only way to circumvent it is to post higher-priority events. Multiple event priorities carry their own drawbacks and must be used with caution and understanding of how the priority scheme is implemented in the event queue.