0

I'm doing:

connect(tcpSocket,SIGNAL(readyRead()), this, SLOT(onTCPDataArrived()), Qt::QueuedConnection);

But the times the slot gets called is much less than it should have.

It seems like it missed a lot of signals, probably because the slot takes a long time(it does).

I added a 2ms delay on the transmission side between tcp writes and it gets better: the slot get called more.

Question: if the signal and slot are in the same thread, it the receiver still queuing incoming signals when the slot is already running?

UmNyobe
  • 22,539
  • 9
  • 61
  • 90
user3528438
  • 2,737
  • 2
  • 23
  • 42

2 Answers2

2

With TCP/IP there are never any guarantees as to how the data is chopped up into packets at the receiving end. So, you might send 10 bytes "all at once", and the receiving end is allowed to receive anywhere between 10 notifications (one for every byte) and 0 notifications. Why zero? Because you possibly could send another 10 bytes soon thereafter, and there will be one notification for all 20 of them. This has nothing to do with Qt at all.

So, when readyRead() fires, you must read all the data that is available for reading. You will not be notified about this data again.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
0

Qt::QueuedConnection documentation stipulates

The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.

It behavior is independent of the thread triggering the signal (not the case with all connection types).

What you are experiencing is a producer tcpSocket which produces at a faster rate than the consumer this. As you said onTCPDataArrived take a lot of time.

You should modify onTCPDataArrived such that :

  • Either it consumes big portions. For instance if the producer notify after writing each character, the consumer can come and read all characters available at once.
  • Either it drops some data.
UmNyobe
  • 22,539
  • 9
  • 61
  • 90
  • Not exactly faster, but a burst, so "this" should be able to queue all the calls and then serve them one after another. I'm wondering either QT:: QueuedConnection is missing signals, or QT::QTcpServer does not emit as many readyRead() signals as I thought: if transmissions are too close together, it only emits readReady() when there's a gap. – user3528438 Feb 26 '15 at 18:28