Qt-Networking-Discussion

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Posted by Jeff Mitchell: http://lists.qt-project.org/pipermail/development/2011-December/000682.html

---

At the Contributor Day in San Francisco, a number of people met to discuss some of the issues involving QtNetwork, especially QNetworkAccessManager (QNAM). The overall idea is that eventually QNetworkAccessManager, which is meant to generally be one-per-application, must be made thread-safe in order to fulfill this desired use.

Here are the notes from the discussion:

Long term: QNAM needs to be thread-safe (and each QNAM will be in its own thread)

• As a result so does the cookie jar and disk cache (and these would not moveToThread())
• After that, implement QNAM::setApplicationNetworkAccessManager()
• QML can stop using multiple QNAMs and QNetworkProxyFactories (QNPFs) too.

Disk cache:

• Get implementation from somewhere which is good enough for most applications
• Set caching on by default: no

Cookie jar:

• Get Alexi to redesign the API
• Need a default persistent cookie jar: possibly?
• Talk to WebKit guys, see if we can make an addon based on their cookie jar

Application proxy:

• Use system proxy by default

System proxy config:

• Global proxy config needs to be in network manager/connection manager so there is a known place to fetch it before system proxies can be supported on non-Windows/MacOS

QNetworkProxyFactory:

• queryProxy() needs to be documented that it must be thread-safe
• proxyForQuery(): unlock mutex before calling user code

QSharedPointer:

• Use for all three (disk cache, cookie jar, qnam) so that the user can keep a ref around if they want (also for the static methods)
• Make QSharedPointer be able to delete properly with a forward declaration
• QObject::connect needs to be able to take a QSharedPointer<QObject>
• QObject::connect needs to be able to take a QWeakPointer<QObject>

Ultra long term (Qt6):

• Fix QIODevice to do zero-copy

---

Update by Thiago Macieira

…see post at: http://lists.qt-project.org/pipermail/development/2011-December/000693.html

> Long term: QNAM needs to be thread-safe (and each QNAM will be in its
> own thread)
> * As a result so does the cookie jar and disk cache (and these would not
> moveToThread())
> * After that, implement QNAM::setApplicationNetworkAccessManager()
> * QML can stop using multiple QNAMs and QNetworkProxyFactories (QNPFs) too.

I've been thinking…

QNAM is still a QObject, and so are the cache and cookie jars. They are perfectly well attached to one thread. So we could still do cookie-jar and cache access from that same thread, with some cross-thread mechanisms.

The cookies should not suffer any performance hit, since they are quite small and limited in use (get them prior to sending the request, save them back after getting the reply).

The cache, however, could be an issue. Imagine I do a get() from an auxiliary thread, one that the QNAM and the cache are not affined to. The implementation would need to read from the cache in one thread and make the data available to the user, in the QNetworkReply, in another thread.

This would, however, make a "clean" solution.