[Development] QtNetwork changes from QtDD SF 2011

Thiago Macieira 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
> 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.

-- 
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: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111205/0068b6d5/attachment.sig>


More information about the Development mailing list