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

[iammilind]

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 QAbstractSocket::waitForReadyRead() (http://doc.qt.io/qt-5/qabstractsocket.html#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() (http://doc.qt.io/qt-5/qiodevice.html#waitForReadyRead).

Question: Is QSslSocket::waitForReadyRead() (http://doc.qt.io/qt-5/qsslsocket.html#waitForReadyRead) consistently usable for all the platforms?

This query is also posted on stackoverflow: https://stackoverflow.com/q/44544684/514235

---

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.

[wysota]

The 'strange reason' is likely that the thread in question is not running an event loop. Since you have the thread there anyway, it's easiest to simply call its exec() to enter the loop. Or don't use the extra thread at all, you don't need it for anything.

[iammilind]

Yes, you are right. However suppose if I want to use `waitForReadyRead()` entirely instead of `readyRead()` signal, would that be fine?