Details
-
Bug
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
6.9
-
None
Description
The default implementation of QQmlTypeLoader::createNetworkAccessManager returns a new QNetworkAccessManager on every request, if the application developer does not set the factory as described in the documentation (https://doc.qt.io/qt-6/qqmlnetworkaccessmanagerfactory.html):
QNetworkAccessManager *QQmlTypeLoader::createNetworkAccessManager(QObject *parent) const { // Can be called from both threads, or even from a WorkerScript // TODO: Calling the user's create() method under the lock is quite rude. // However, we've been doing so for a long time and stopping the // practice would expose thread safety issues in user code. // ### Qt7: Maybe change the factory interface to provide a different method // that can be called without the lock. if (const auto factory = QQmlNetworkAccessManagerFactoryPtrConst(&m_data)) return factory->create(parent); return new QNetworkAccessManager(parent); }
As vminenko correctly found on QTBUG-136048, this is not in line with what we suggest in the documentation of QNetworkAccessManager, where we write:
"One QNetworkAccessManager instance should be enough for the whole Qt application. Since QNetworkAccessManager is based on QObject, it can only be used from the thread it belongs to." https://doc.qt.io/qt-6/qnetworkaccessmanager.html
It seems reasonable to have a default implementation that follows our own documentation and reduces the numbers of QNetworkAccessManagers in apps where application developers do not explicitly take care of it.
Having a single QNetworkAccessManager instance would further simplify resetting it, if that is required e.g. through changing network connections.
Attachments
Issue Links
- resulted from
-
QTBUG-136048 Analyse and resolve side effects resulting in drops of connectivity in Qt Quick apps when network connections change
-
- Reported
-