Priority: Not Evaluated
Affects Version/s: 5.4.0, 5.5.0
Fix Version/s: None
Component/s: Network: Sockets
This change: https://codereview.qt-project.org/#/c/104120/
has caused a problem when using QUdpSocket where it will stop emitting the readyRead signal after a while.
We use the (faulty) QUdpSocket for reading only and we have different sending (UDP) streams.
One version uses a file based input, which is highly regular and when we use this the behaviour is as expected: we get readyRead every time data arrives.
The other version uses sampled data from a device, which gets processed etc, which causes the timing of packets wrt each other to vary much more. If we stream from this part (using the exact same protocols and objects), after a few received packets the QUdpSocket will stop emitting the readyRead signal.
It just suddenly stops. The object still exists, its connections are still there, etc. If we check the buffers, we can see that there is actually data in the queue, just the signal is never emitted anymore.
After much digging around, we reverted the mentioned change (which has caused a change in the behaviour of temporarily disabling this particular signal) and after we revert this, we get the expected behaviour for QUdpSocket again (ie. everything works and we keep getting the readyRead signal)
I suspect that the new check socketEngine->hasPendingDatagrams() causes a race condition. Perhaps my function already stopped reading datagrams because there are no more, but it hasn't returned yet, then a new datagram arrives and then no readyRead is emitted, then my function returns and the signal could be enabled, but now there already is a datagram in the queue which disables the signal again.
We've reverted the change locally, since we're not experiencing the problem that it was supposed to fix, but I expect that this should be fixed properly