[Development] QtNetwork changes from QtDD SF 2011
thiago.macieira at intel.com
Tue Dec 6 00:32:59 CET 2011
On Monday, 5 de December de 2011 14.50.23, Jeff Mitchell wrote:
> At the Contributor Day in San Francisco, a number of people met to
> discuss some of the issues involving QtNetwork, espcially
> 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:
Hi Jeff, thanks for posting this.
[shame on me for not posting the one I chaired in MUC]
> 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
> * 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.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/development/attachments/20111205/0068b6d5/attachment.bin
More information about the Development