[Qt-interest] QNetworkAccessManager and a QHash of QNetworkReply pointers

Mandeep Sandhu mandeepsandhu.chd at gmail.com
Mon Sep 6 09:59:19 CEST 2010


> What I noticed on Friday was that:
> 1. namFin was called before repFin. IMHO, I think that it's illogical, I would imagine that the NAM would emit finished() once reply has finished(), being a _manager_ after all.

Is there any specific reason why you would want to treat these 2
signals, i.e namFin and repFin differently? They both signal the same
event.

You can read your incoming data in the slot handling readyRead()
signal. In repFin() OR namFin() signal you can then safely remove your
reply pointer from your hash and delete it using reply->deleteLater().

The QT docs state that the finished signal's (of QNAM and QNReply) are
emitted in "tandem". I don't think you should rely on their order of
emitting to do some processing.

HTH,
-mandeep

>
> 2. When our application starts up, there are two network fetches that work as planned, and they are not handled in parallel: first we make a software update check, once that finishes we check if some client-specific settings have changed on our server. Here the logic works as planned: namRep removes autoupdater's reply from the hash, client data checker is added to the hash and promptly removed once that fetch completes.
>
> 3. But, the phase of app startup fails: we start to download data from five servers and NAM operates those fetches in parallel. namFin tries to remove keys&values from the hash using hash's remove function, but nothing was actually removed from the hash. This caused an access violation exception when using the application since our app was of the opinion that there is a fetch going on (there are entries in the hash), but the underlaying system (OS/Qt framework) had already freed the memory related to that pointer.
>
> 4. When I relocated the hash remove function call to repFin instead of namFin the hash entry logic started to work.
>
> Is my problem in the order of finished() signals? Is the combination of calling deleteLater for a reply before the reply itself has finished poisonous? What kind of magic is going on in the background?
>
> Slaínte,
> --
> jussi
>
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>




More information about the Qt-interest-old mailing list