How to design a state machine in face of non-blocking I/O?

[piotr.dobrogost]

When the other subsystem is in "IDLE" state and CONNECT is received (...)

This means you have to check the state of the other (let's call it network) subsystem from outside of it. I was looking for some method allowing to find out which state a QStateMachine is in but don't see any such... When you think of it it's logical there is no such a method as a state machine itself is a tool that should be used to handle logic internally. This reminds me of Untangling the Signal Slot Spaghetti with SCXML where the author states that the very important purpose of state machines is to remove handling program flow manually with if and switch statements. As you know instead of having one Idle state in the first subsystem (let's call it user subsystem) and checking what the state of the other one is we could just introduce new states like Idle-Connected and Idle-LoggedIn and this way we wouldn't need to check manually for the state of network subsystem from within user subsystem. This represents going from if type of managing program's logic to state machine type of managing program's logic. Dividing my current state machine into two new ones and checking (using if) what's the state of the other one is like going in opposite direction. Any thoughts?

When you receive the network event, move into the idle state and output CONNECTED (which will move the other subsystem to the CONNECTED state).

I thought the idea was to direct network events from withing LoadFinished handler directly to this other subsystem which is responsible for network state. Would it be viable? Would it be better? Wouldn't then be an issue of synchronization between the two subsystems?

It is the same: "<state of other machine>, <external input> / <output>"

Ok.

you can remove the dead transitions if you want.

Ok.