[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Wanted: best KDE practice for dealing with blocking work jobs
From: Michael Pyne <mpyne () purinchu ! net>
Date: 2008-06-18 19:16:41
Message-ID: 200806181516.48519.mpyne () purinchu ! net
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
[Attachment #4 (multipart/alternative)]
On Wednesday 18 June 2008, Lubos Lunak wrote:
> On Monday 16 of June 2008, Rafael Fernández López wrote:
> > void NetAccess::enter_loop()
> > {
> > QEventLoop eventLoop;
> > connect(this, SIGNAL(leaveModality()),
> > &eventLoop, SLOT(quit()));
> > eventLoop.exec(QEventLoop::ExcludeUserInputEvents);
> > }
>
> ...
>
> > Is a great way of making asynchronous calls synchronous ones, without
> > blocking the GUI. On your situation (from what I get), is everything
> > synchronous, but the basics from this example can be applied.
>
> It is a great way only until you run into the first bug caused by
> re-entering of the event loop. You should not be too careless with this,
> there are many places in the code that really don't expect that a
> harmlessly looking call will in fact fire off timers, delete some objects
> and whatnot.
This is no lie. I've "fixed" quite a few JuK crashers that are due to calling
things like kapp::processEvents(), even with excluding user input, as it would
cause incompatible changes while the processing was underway.
Regards,
- Michael Pyne
[Attachment #7 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" \
"http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" \
content="1" /><style type="text/css">p, li { white-space: pre-wrap; \
}</style></head><body style=" font-family:'Consolas'; font-size:11pt; \
font-weight:400; font-style:normal;">On Wednesday 18 June 2008, Lubos Lunak \
wrote:<br>> On Monday 16 of June 2008, Rafael Fernández López wrote:<br>> \
> void NetAccess::enter_loop()<br>> > {<br>> > QEventLoop \
eventLoop;<br>> > connect(this, SIGNAL(leaveModality()),<br>> > \
&eventLoop, SLOT(quit()));<br>> > \
eventLoop.exec(QEventLoop::ExcludeUserInputEvents);<br>> > }<br>><br>> \
...<br>><br>> > Is a great way of making asynchronous calls synchronous \
ones, without<br>> > blocking the GUI. On your situation (from what I get), is \
everything<br>> > synchronous, but the basics from this example can be \
applied.<br>><br>> It is a great way only until you run into the first bug \
caused by<br>> re-entering of the event loop. You should not be too careless with \
this,<br>> there are many places in the code that really don't expect that \
a<br>> harmlessly looking call will in fact fire off timers, delete some \
objects<br>> and whatnot.<br><p style="-qt-paragraph-type:empty; margin-top:0px; \
margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; \
text-indent:0px; -qt-user-state:0;"></p>This is no lie. I've "fixed" quite a few JuK \
crashers that are due to calling things like kapp::processEvents(), even with \
excluding user input, as it would cause incompatible changes while the processing was \
underway.<br><p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; \
margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"></p>Regards,<br> - Michael Pyne</p></body></html>
["signature.asc" (application/pgp-signature)]
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic