Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.12.3
-
e24a4976bebd7ca90deac2b40c08900625773a99 (qt/qtbase/5.12)
Description
Since 5.9 (QTBUG-56424, ChangeId I49053ac2859e6c6c07e4a704b8b5f0d6a2d0b8a4) additional overloads for QHostInfo::lookupHost have been introduced.
Looks like those don't work as expected.
I would have expected that by specifying a QObject as a receiver context
a) it should be safe when the receiver no longer exists when a result is available
b) the slot or functor should be invoked in the receiver's thread.
Quoting the documentation "If context is destroyed before the lookup completes, the functor will not be called. The functor will be run in the thread of context. The context's thread must have a running Qt event loop."
Both my assumption seem to be wrong. The following example demonstrates the problem.
#include <QCoreApplication> #include <QDebug> #include <QtNetwork> class Receiver : public QObject { Q_OBJECT int dummy = 43; public: Receiver(QObject *parent = nullptr) : QObject(parent) { qDebug() << "CTR" << this; } ~Receiver() { qDebug() << "DTR" << this; } public slots: void received(const QHostInfo &info) { // this will be called from network thread when // invoked via "mordern connect syntax" but // from the main ui thread when using the "old connect syntax" qDebug() << "Result" << info.addresses() << dummy; } }; int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); { Receiver r; // crashes, because member is invoked directly via QSlotObjectBase:call QHostInfo::lookupHost("www.spiegel.de", &r, &Receiver::received); } { // safe, handled by queued signal dispatching Receiver r; QHostInfo::lookupHost("www.zeit.de", &r, SLOT(received(QHostInfo))); } return a.exec(); } #include "main.moc"
I would have expected that both invocations behave exactly the same, however only the old connect-syntax actually works.
Attachments
Issue Links
- is duplicated by
-
QTBUG-83073 QHostInfo::lookupHost calls back from another thread
- Closed