[Interest] Strange problem where exec() of dialogs returns immediately

[Thiago Macieira]

On domingo, 11 de março de 2012 19.39.31, Nikos Chantziaras wrote:
> > Note how even you had to force an event loop by that horrible while (true)
> > construct. Remove it completely. Once you solve the problem of the last
> > window closing too soon, the main event loop will take care of the main
> > window's lifetime.
> 
> It's not optimal, but needed.

No, it's not. It's wrong and you must get rid of it. There must be another 
construct that avoids that mistake. It also has the mistake that you don't 
have access to the quit flag, inside the loop, so you don't know when exiting 
was requested.

> The application is an engine for running 
> programs in it, and those programs have their own internal event loops. 
>   They call callbacks so the host application can advance its own event 
> loop.  In those callbacks I then do processEvents().  There's no way 
> around that.

Yes, there is. You can use threads or you can use a custom event dispatcher. 
And this is assuming that you tried but was unable to integrate the loops by 
way of timer and socket notifier callbacks. Your choice should be:

1) if the library provides you with callbacks for when it updates timers and 
socket notifiers, use the standard Qt event loop

2) if the library does not provide that, but allows you to add sockets 
notifiers and timers, then you should write your own Qt event dispatcher 
(inheriting from QAbstractEventDispatcher) and register the Qt sources with 
that lib.

3) if the library does not provide either, you put its use in a thread

Anything else is sub-optimal because you'll either wake up too often or you'll 
delay event processing. Or, more likely, both, which is worse.

> Even though I've dealing with this for years, I'm still not sure how to 
> correctly advance Qt's event loop.  For example is:
> 
>    qApp->sendPostedEvents(0, QEvent::DeferredDelete);

The correct way is app->exec() or loop->exec(), where loop is a QEventLoop 
object.

Everything else is workaround.

> even needed?  I think it takes care of deleting objects (for 
> deleteLater() calls), but seems to produce 100% CPU load on Mac OS X.

I explained above. You wake up too often.

As long as you use this sub-optimal construct, you'll use more CPU than you 
need to and you'll delay processing. Find another way.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- 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/interest/attachments/20120311/5dd96f18/attachment.sig>