The problem between HTTP and QEvetnLoop
-
QNetworkAccessManager* m_httpManager = new QNetworkAccessManager();
QDateTime m_LastReemoonDeviceErrData = QDateTime::currentDateTime();while (true) { int reemoonDeviceErrDataTimeCount = m_LastReemoonDeviceErrData.secsTo(QDateTime::currentDateTime()); if(reemoonDeviceErrDataTimeCount >=3){ m_LastReemoonDeviceErrData = QDateTime::currentDateTime(); QString url = "http://192.168.10.29:8899/Api/Customer/GetCustomerDeviceInfo"; QString postData = ""; QNetworkRequest request; request.setUrl(QUrl(url)); request.setHeader(QNetworkRequest::ContentTypeHeader,QVariant("application/json")); QMap<QString, QString> headers; QMapIterator<QString, QString> iterator(headers); while (iterator.hasNext()) { iterator.next(); request.setRawHeader(iterator.key().toUtf8(),iterator.value().toUtf8()); } QNetworkReply* reply = m_httpManager->post(request,postData.toUtf8()); /* QEventLoop eventLoop; connect(reply, &QNetworkReply::finished, [&](){ QString result = reply->readAll(); //qDebug()<<QDateTime::currentDateTime()<<reply->errorString()<<"----"<<result; reply->deleteLater(); eventLoop.quit(); }); eventLoop.exec();*/ //添加事件循环机制,返回后再运行后面的 QEventLoop eventLoop; connect(reply, &QNetworkReply::finished, &eventLoop, &QEventLoop::quit); eventLoop.exec(); QString result = reply->readAll(); reply->deleteLater(); } //QThread::msleep(3000); } if(m_httpManager) { m_httpManager->deleteLater(); }
If using GDB to run this program, there will be a thread constantly creating and exiting. What is the reason for this?
[New Thread 0x7fffc5f50700 (LWP 100506)]
[Thread 0x7fffc5f50700 (LWP 100506) exited]
[New Thread 0x7fffc5f50700 (LWP 100511)]
[Thread 0x7fffc5f50700 (LWP 100511) exited] -
You are creating event loops in a loop, that's probably the reason for all these threads.
It is much better to not wait in loop like this. Use signals and slots to respond to replies as they come. You can send a new request in the slot answering to
QNetworkReply::finished
, for example: this will behave the same but without waiting, without an infinite loop and without custom QEventLoops. -
You are creating event loops in a loop, that's probably the reason for all these threads.
It is much better to not wait in loop like this. Use signals and slots to respond to replies as they come. You can send a new request in the slot answering to
QNetworkReply::finished
, for example: this will behave the same but without waiting, without an infinite loop and without custom QEventLoops.@sierdzio yes,I know, but I have to wait for the result returned by HTTP before proceeding to the next step. If I use signals and slots, I won't be able to synchronize the results. What should I do?
-
I don't see why you won't be able to synchronize the results. Handle the results when you get a
finished
signal. This will involve splitting your current code into smaller functions, but that is only good for the code in general. -
I don't see why you won't be able to synchronize the results. Handle the results when you get a
finished
signal. This will involve splitting your current code into smaller functions, but that is only good for the code in general.@sierdzio Because this is a loop, I have to wait for the corresponding return value every time. If I use signals and slots, will it cause the first return value to respond only when the second request is made?
-
I'm saying you should break the loop. Remove it completely.
The loop can be replaced completely by signals and slots:
- Entry point, you set up your initial conditions.
- Execute HTTP request.
- In slot, you read the reply and decide if another request is needed. If yes, then you call method 2. again.
- If no new request is needed, you don't call method 2. but instead do the next steps you want to do now that you have your complete information downloaded from HTTP server.
I realise this might be sometimes a bit hard to fit into existing application logic, but it is a simple and easy system, will be easy to maintain.
-
I'm saying you should break the loop. Remove it completely.
The loop can be replaced completely by signals and slots:
- Entry point, you set up your initial conditions.
- Execute HTTP request.
- In slot, you read the reply and decide if another request is needed. If yes, then you call method 2. again.
- If no new request is needed, you don't call method 2. but instead do the next steps you want to do now that you have your complete information downloaded from HTTP server.
I realise this might be sometimes a bit hard to fit into existing application logic, but it is a simple and easy system, will be easy to maintain.
@sierdzio ok,I try it,thank you