Recently discovered that Tangram sent out a URL request, but could not receive the URL reponse
The study found that this is a threading problem: Tangram sends URL request on multiple threads, but when implemented, it does not take into account threading issues, and the program gets the following warning at run time:
QObject: Cannot create children for a parent that is in a different thread.
(Parent is QNetworkAccessManager(0x21dcba0), parent‘s thread is QThread(0x20be1c0), current thread is QThread(0x7f48e0044730)
When porting Tangram to the QT platform, the network request is Qnetworkaccessmanager, and the Qnetworkaccessmanager is simple to use:
QNetworkAccessManager *manager = new QNetworkAccessManager(this);
connect(manager, SIGNAL(finished(QNetworkReply*)), this, SLOT(replyFinished(QNetworkReply*)));
manager->get(QNetworkRequest(QUrl("http://qt-project.org")));
The problem here is that Tangram may send a URL on multiple threads, but Qnetworkaccessmanager can only work on the thread where it was built, and the workaround is to use the signal/slot mechanism of QT to put the URL Request post to the correct thread:
class URLTaskWorker{ public:
URLTaskWorker(){
connect(this,SIGNAL(startRequest()),this, SLOT(onRequest()), Qt::QueuedConnection);
} public: void handleTask(QUrl url){ this->url = url;
emit StartNewRequest();
}
signals: void startRequest(); private slots: void onRequest(){
qnam.get(url);
} private:
QNetworkAccessManager qnam;
QUrl url;
};
It is important to note that in Connect startrequest and onrequest , to use the qt::queuedconnection, the default Qt is used : Autoconnection does not work, refer to the QT Help documentation:
Qt::QueuedConnection
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.
This is also a thread-safe way for QT to pass messages between different threads.
Using Qnetworkaccessmanager in multiple threads