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

[wysota]

This means you have to check the state of the other (let's call it network) subsystem from outside of it.

Yes, of course.

I was looking for some method allowing to find out which state a QStateMachine is in but don't see any such...

How about using onEntry() and onExit()?

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.[/quote]
That's true but nobody says you have to do that. Transitions are fired upon some external input - all you need to do is to make one machine provide input to the other.

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?

Try and see for yourself, I'm not an oracle

[piotr.dobrogost]

How about using onEntry() and onExit()?

You mean to make the machine itself store its state outside and read it from there?
That wouldn't be atomic operation then. Don't know if that would be a problem but... Let's forget for a moment about my case. Each QStateMachine has its own event loop so it works fully asynchronously. Having non-atomic read of machine's state doesn't sound like a safe approach in this situation. What do you think?

That's true but nobody says you have to do that. Transitions are fired upon some external input - all you need to do is to make one machine provide input to the other.

So how would you code, without using conditional statements, let's say the transition Idle -- LOGGEDIN/<QUERY>/- --> Querying from your Rysunek1? To me it looks like you have to make _decision_ (so use conditional statement) in your code based on the information weather the network state machine is in LoggedIn state or it's not...

Try and see for yourself, I'm not an oracle

I thought programming is not about trying but about thinking, knowing and being sure something is right

[wysota]

You mean to make the machine itself store its state outside and read it from there?

Something like that.

That wouldn't be atomic operation then.

Why not? It would be atomic from the state machine's point of view. The number of event loops doesn't matter. The thread count matters (if at all).

So how would you code, without using conditional statements, let's say the transition Idle -- LOGGEDIN/<QUERY>/- --> Querying from your Rysunek1? To me it looks like you have to make _decision_ (so use conditional statement) in your code based on the information weather the network state machine is in LoggedIn state or it's not...

I don't understand the problem Maybe you should try to write some code and then we could work on it?

I thought programming is not about trying but about thinking, knowing and being sure something is right

Then you were simply wrong

[piotr.dobrogost]

Something like that.

Ok. What do you think about the fact there is no function to obtain current state in QStateMachine's API although the state in which a state machine is, well it's the most important part of its state as an object?

I don't understand the problem Maybe you should try to write some code and then we could work on it?

NetworkMachine * netMachine;
 
class UserMachine
{
public:
    class UserTransition : public QAbstractTransition
    {
     //...
     }
     //...
}
 
 
bool UserMachine::UserTransition::eventTest(QEvent * event )
{
   if (event.type() == UserMachine::EventType::Query)
   {
      // we are forced to use switch here...
      switch (currentState(netMachine))
      {
        case NetworkMachine::Connected:
        case NetworkMachine::LoggedIn:
        case NetworkMachine::Result:
          return true;
        default:
          return false;
       }
    }
 
}

NetworkMachine * netMachine;

class UserMachine
{
public:
    class UserTransition : public QAbstractTransition
    {
     //...
     }
     //...
}


bool UserMachine::UserTransition::eventTest(QEvent * event )
{
   if (event.type() == UserMachine::EventType::Query)
   {
      // we are forced to use switch here...
      switch (currentState(netMachine))
      {
        case NetworkMachine::Connected:
        case NetworkMachine::LoggedIn:
        case NetworkMachine::Result:
          return true;
        default:
          return false;
       }
    }

}

To copy to clipboard, switch view to plain text mode 

We need this switch statement above because we have to decide if we're doing transition or not based on the state of the network machine.
If we had more states in the user machine we wouldn't have to check the state of network machine. We would had enough number of states we wouldn't have need the network machine at all... What do you think?

[wysota]

Ok. What do you think about the fact there is no function to obtain current state in QStateMachine's API although the state in which a state machine is, well it's the most important part of its state as an object?

There are the entered() and exited() signals in QState. That should be enough for everything.

The code doesn't do anything yet, so I'm not going to comment on that.

[piotr.dobrogost]

The code doesn't do anything yet, so I'm not going to comment on that.

What do you mean? It shows that when user machine gets <query> event it has to check the state of network machine and based on this information make a decision weather to trigger transition or not.

bool QAbstractTransition::eventTest ( QEvent * event ) [pure virtual protected]
This function is called to determine whether the given event should cause this transition to trigger. Reimplement this function and return true if the event should trigger the transition, otherwise return false.

[wysota]

What do you mean? It shows that when user machine gets <query> event it has to check the state of network machine and based on this information make a decision weather to trigger transition or not.

Get something that compiles and runs.