Two QTcpSocket compete for one function, why is there a parallel challenge in one flow?



  • Hello, everyone!

    There's a class in which two QTcpSocket and one QTimer.

    StateTimer = new QTimer(this);
    ControlSock = new QTcpSocket(this);
    StatSock = new QTcpSocket(this);
    

    For them, 5 slots are identified inside the class and all are connected like this.

    QObject::connect(StateTimer, SIGNAL(timeout()), this, SLOT(Timer_slot()));
    QObject::connect(ControlSock, SIGNAL(stateChanged(QAbstractSocket::SocketState)),   this, SLOT(ControlSockStateChange_slot(QAbstractSocket::SocketState)));
    QObject::connect(StatSock, SIGNAL(stateChanged(QAbstractSocket::SocketState)), this, SLOT(StatSockStateChange_slot(QAbstractSocket::SocketState)));
    QObject::connect(ControlSock, SIGNAL(error(QAbstractSocket::SocketError)), this, SLOT(ControlSockError_slot(QAbstractSocket::SocketError)));
    QObject::connect(StatSock, SIGNAL(error(QAbstractSocket::SocketError)), this, SLOT(StatSockError_slot(QAbstractSocket::SocketError)));
    

    The same function is required in all slots. I did this.

    counter++;
    qDebug() << "call: " << (int) QThread::currentThreadId();
    qDebug() << "counter: " <<counter;
    ....
    counter--;
    return;
    

    In my perfect world, whatever happened to the network and the timer, the function should always be "counter: one." However, when the connection breaks (physically ripped the cable) when two skets are broken once once, and there are six functional challenges, other than two alterations. But not sequentially, but parallel! I get the tape.

    call: 9600 counter: 1

    call: 9600 counter: 2

    call: 9600 counter: 3

    call: 9600 counter: 4

    call: 9600 counter: 5

    Explain to the good people what the hell is going on? How can a function be challenged from one event flow several times? Inside of the function, naturally, there are no queue processing agents.

    And the second question, if I make a signal-- the slot, the connection in the motor mode, and then one of the objects in another tride, is it from the straight to the line to switch automatically? Or should we keep track of this and connect it after we swallowed the objects on the trids or immediately put the right types of connection? Or is the type of challenge determined on the road?



  • The reason for such behaviour is that the function was to work with the sockets.

    if(ControlSock->state() != QAbstractSocket::UnconnectedState)
      ControlSock->abort();
    

    or

    if(ControlSock->state() != QAbstractSocket::UnconnectedState)
       ControlSock->disconnectFromHost();
    

    There were additional signals inside these methods that were directly challenged again in the same function. Since the function is one on both skate, I've caught signals from both.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2