问题描述
我有一个 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.
这篇关于“停止/关机”的正确方法是什么? QNetworkAccessManager?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!