[Qt-interest] QNetworkAccessManager in GUI thread

Nitin Mahajan nitinm76 at yahoo.com
Tue Feb 2 08:24:55 CET 2010



--- On Mon, 1/2/10, Nitin Mahajan <nitinm76 at yahoo.com> wrote:

> From: Nitin Mahajan <nitinm76 at yahoo.com>
> Subject: Re: [Qt-interest] QNetworkAccessManager in GUI thread
> To: qt-interest at trolltech.com, "Thiago Macieira" <thiago at kde.org>
> Date: Monday, 1 February, 2010, 7:47 PM
> Hello,
> 
> --- On Fri, 22/1/10, Thiago Macieira <thiago at kde.org>
> wrote:
> 
> > From: Thiago Macieira <thiago at kde.org>
> > Subject: Re: [Qt-interest] QNetworkAccessManager in
> GUI thread
> > To: qt-interest at trolltech.com
> > Date: Friday, 22 January, 2010, 12:03 AM
> > Em Quinta-feira 21 Janeiro 2010, às
> > 12:33:14, Nitin Mahajan escreveu:
> > > Hello,
> > > 
> > > In a GUI application like Demo Browser, I have a
> > QNetworkAccessManager
> > > object say "A" created in the GUI thread itself.
> > > 
> > > I want to do the actual file download in a
> separate
> > thread, so that my
> > > GUI/mouse cursor does not freeze. Can I create a
> new
> > QNetworkAccessManager
> > > "B" in the new thread and set the cookiejar and
> proxy
> > from "A" and still
> > > download?
> > 
> > No.
> > 
> > QNetworkAccessManager, all its QNetworkReply objects,
> > QNetworkCookieJar, 
> > QAbstractNetworkCache, etc., must all live in the
> same
> > thread.
> > 
> > > While doing the download in the GUI thread itself
> I
> > can see the mouse
> > > cursor freezing, even though the replies of the
> > requests sent through
> > > NetworkAccessManager arrive asynchronously.
> Whether
> > Network acccess
> > > manager does some operation which is still
> Blocking?
> > 
> > Nothing is blocking. Everything is asynchronous.
> > 
> > My guess is that your device is just that much
> > underpowered. It would be 
> > interesting to profile the application and find out
> where
> > the bottleneck is.
> > 
> 
> I did run the browser through 'ltrace' to find out the
> bottleneck.
> I did
> 
> #ltrace  -C -c -p  5190
> % time     seconds 
> usecs/call     calls     
> function
> ------ ----------- ----------- ---------
> --------------------
>  95.35    9.867098       
> 4882      2021 QApplication::notify(QObject*,
> QEvent*)
>   1.08    0.111444     
>    165       674
> QIODevice::write(char const*, long long)
>   0.82    0.084883     
>    125       674
> QIODevice::readAll()
>   0.71    0.073494     
>    108       675
> QApplication::compressEvent(QEvent*, QObject*,
> QPostEventList*)
>   0.70    0.072156     
>    107       674
> qFree(void*)
>   0.68    0.070630     
>    104       674
> QIODevice::isOpen() const
>   0.67    0.068849     
>    102       674
> QWidget::qt_metacall(QMetaObject::Call, int, void**)
> ------ ----------- ----------- ---------
> --------------------
> 100.00   10.348554     
>             6066 total
> 
> and at another instance the output of ltrace is 
> 
> ltrace -C -c -p  32182
> % time     seconds 
> usecs/call     calls     
> function
> ------ ----------- ----------- ---------
> --------------------
>  78.47    2.219333       
> 1392      1594 QIODevice::write(char const*,
> long long)
>   6.13    0.173351     
>    108      1594
> QIODevice::readAll()
>   5.33    0.150667     
>     94      1594
> QIODevice::isOpen() const
>   5.14    0.145472     
>     90      1600
> QApplication::compressEvent(QEvent*, QObject*,
> QPostEventList*)
>   4.93    0.139285     
>     87      1594
> QWidget::qt_metacall(QMetaObject::Call, int, void**)
> ------ ----------- ----------- ---------
> --------------------
> 100.00    2.828108       
>           7976 total
> 
> 
> With this I think the QIODevice::write() call is the
> culprit. 
> Whether this understanding of mine is correct?
> 
> If that is true the QIODevice::write is called from 
> 
> 1. QHttpNetworkReplyPrivate::transferRaw(writing to Buffer)
> and
> 
> 2. from the application while writing file from
> DownloadItem::downloadReadyRead().
> 
> I tried making the connections as Qt::QueuedConnection, but
> did not help.
> Since NAM and its related objects have to be in same
> thread, its difficult to seperate out these two operations
> in different threads.
> 
> If I disconnect DownloadItem::downloadReadyRead(), still
> the UI freezes.

This particular case is fine now, once I limit the QNetworkReply objects read buffer size by a call to setReadBufferSize().

However once I connect the DownloadItem::downloadReadyRead(), the readAll() still spends time and during this time the mouse movement becomes jumpy.

Can I get some hints on how to solve this issue?

regards

-Nitin

> 


> Can I get some pointers on how to approach this?
> 
> regards
> 
> -Nitin
> 
> 
> 
> 
> > -- 
> > Thiago Macieira - thiago (AT) macieira.info - thiago
> (AT)
> > kde.org
> >   Senior Product Manager - Nokia, Qt Development
> > Frameworks
> >       PGP/GPG: 0x6EF45358; fingerprint:
> >       E067 918B B660 DBD1 105C  966C
> > 33F5 F005 6EF4 5358
> > 
> > -----Inline Attachment Follows-----
> > 
> > _______________________________________________
> > Qt-interest mailing list
> > Qt-interest at trolltech.com
> > http://lists.trolltech.com/mailman/listinfo/qt-interest
> > 
> 
> 
>       Get your preferred Email name!
> Now you can @ymail.com and @rocketmail.com. 
> http://mail.promotions.yahoo.com/newdomains/aa/
> 
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
> 


      New Email names for you! 
Get the Email name you&#39;ve always wanted on the new @ymail and @rocketmail. 
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/




More information about the Qt-interest-old mailing list