[Qt-interest] QNetworkAccessManager in GUI thread

Nitin Mahajan nitinm76 at yahoo.com
Tue Feb 2 09:04:40 CET 2010


Helo,

--- On Tue, 2/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
> Date: Tuesday, 2 February, 2010, 12:54 PM
> 
> 
> --- 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().

I think this observation of mine is not correct. Please ignore this particular point.
> 
> However once I connect the
> DownloadItem::downloadReadyRead(), the readAll() still
> spends time and during this time the mouse movement becomes
> jumpy.
The readAll() and the write() calls are the one which are spending significant amount of time, as reported by ltrace.

How to manage these operations, so that they do not freeze the UI?

regards

-Nitin

> 
> 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've always wanted on the new
> @ymail and @rocketmail. 
> Hurry before someone else does!
> http://mail.promotions.yahoo.com/newdomains/aa/
> 
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
> 


      Get your new Email address!
Grab the Email name you&#39;ve always wanted before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/




More information about the Qt-interest-old mailing list