[Qt-interest] Controlling when timers run

Glenn Hughes ghughes02138 at gmail.com
Thu Jan 14 23:30:50 CET 2010


>Ah OK so the problems occur when you enter a local event loop such as
>you get when calling QDialog::exec() and your timers continue to get
>fired from that event loop?

Yes, or also possibly inside of other system calls. I haven't actually
seen problems occur under Qt, but I know that we've had these problems
under Mac OS, so I need to know exactly how things function in the Qt
world.

We've often had bugs with stacks that look something like

Timer callback (accessing changed data structures... kaboom)
OS call (like, drawing or making a window or something)
Our code (handling an event, and changing data structures)
OS stuff (event loop)
main

This is because our app came from the OS 9 days (i.e. old Mac OS)
where we had the ability to do this:

MainEventLoop()
{
       WaitNextEvent(ev)
       HandleEvent(ev)
       DoStuffInTheBackground()
}

As you can see, "DoStuffInTheBackground" will only ever be called when
the stack as fully unwound to the main event loop. It will never be
called inside of "HandleEvent"

Under OS X we now have two types of timers, ones that can run any
time, and ones that can only run when the stack is fully unwound.
Because we have access to all our entry points, we can block the "only
unwound" style timers whenever the OS calls into our code (i.e. from
our Carbon event handlers)... Since all this stuff is wrapped inside
of Qt (and rightly so), it would be great if I had some other
mechanism for determining if the stack was fully unwound back to the
main event loop, or not.

Thanks!
G



More information about the Qt-interest-old mailing list