Is it OK to use `waitForReadyRead()` instead of creating a slot for `readyRead()` signal?

Question

Writing a cross platform app using Qt (including Windows with MinGW). For reading data from SSL socket, I am creating a separate thread. This thread is there for historical reason, because earlier the app was written using C socket/ssl/crypto libraries. Now all these are being replaced with Qt Network library.

For blocking thread, waitForReadyRead(milliseconds) seems a better choice. Now according to Qt hierarchy:

QIODevice
   |
QAbstractSocket
   |
QTcpSocket
   |
QSslSocket

Documentation of QAbscractSocket::waitForReadyRead() suggests:

Note: This function may fail randomly on Windows. Consider using the event loop and the readyRead() signal if your software will run on Windows.

But the similar warning is Not mentioned in the QIODevice::waitForReadyRead().

Question: Is QSslSocket::waitForReadyRead() consistently usable for all the platforms?

---

_{Why am I not using readyRead() signal?
For some strange reason, if I slot some method with readyRead() then it's not getting called. Moreover, the QSslSocket::write() also doesn't work, which works otherwise with above approach. Due to complexity of my code, I am unable to present it here.}

Answer 1

To your question: yes you can use QSslSocket::waitForReadyRead() but on Widows it can timeout even when the data came to the socket. So if timeout occurs you have to check if it is timeout or the method failed. The check is simple just if QAbstractSocket::bytesAvailable() > 0 then data are ready for read otherwise it's timeout.

This approach is ok when you use small timeout and your application isn't sensitive on delay (e.g. communication between temperature sensor and cloud with temperature history). But if any unnecessary delay is not acceptable for you then you should use the signal/slot interface.

For more information you can look at the bug report on the Qt's bug tracker.