“停止/关机”的正确方法是什么？ QNetworkAccessManager？

本文介绍了“停止/关机”的正确方法是什么？ QNetworkAccessManager？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我有一个 QNetworkAccessManager 。假设我有一个待处理的请求：

QNetworkRequest request（url）; this-> m_networkManager-> get（request）

我可以关闭 QNetworkAccessManager 可以吗？我之所以问是因为在挂起的get请求期间销毁对象 m_networkManager 时，看到了写访问冲突。

或者我如何安全地销毁管理器，似乎没有停止或关闭功能。

解决方案

根本原因是我们的 QNetworkAccessManager 用于线程工作程序（1）。因此，很明显，当删除 QNetworkAccessManager 并在此步骤中（然后才）清理挂起的 QNetworkReply 对象时，问题出现。

分析：没有待处理的答复，或者在主线程中使用时，在相同的情况下没有问题。如果 QNetworkAccessManager 在移回主线程之前被删除，则可以避免该问题。结论（或推测）：当 QNetworkAccessManager 试图删除在另一个线程中创建的 QNetworkReply 时，会发生此问题。 / p>

（1）应该理解，请求是异步执行的-对于线程工作者，我们有很好的设计理由。

I have a QNetworkAccessManager . Let's assume I have a pending request:

QNetworkRequest request(url); this->m_networkManager->get(request)

Can I shutdown the QNetworkAccessManager at any time? I am asking because I see a write access violation when I destruct my object m_networkManager during a pending get request.

Or how can I safely destroy the manager, there seems to be no stop or shutdown functionality.

解决方案

The root cause is that our QNetworkAccessManager is used in a threaded worker (1). So obviously when the QNetworkAccessManager is deleted, and in this step (and only then) cleans up pending QNetworkReply objects, the problem arises.

Analysis: With no pending replies, or when used in the main thread, there is no issue in the same scenario. The issue can be avoided if the QNetworkAccessManager is deleted just before it is moved back to the main thread. Conclusion (or speculation): The issue occurs when the QNetworkAccessManager tries to delete a QNetworkReply created in a different thread.

(1) It is understood that requests are performed asynchronously - we have good design reasons for the threaded worker.