[Interest] Expected event execution order in this multi-thread application
thiago.macieira at intel.com
Sun Oct 6 19:18:44 CEST 2019
On Saturday, 5 October 2019 06:13:56 PDT Richard Weickelt wrote:
> >> Because I attached a debugger and stopped T1 during
> >> QCoreApplication::processEvents(). I can see E3 (the one that the thread
> >> is
> >> currently processing) in postEventList at index 0 and E2 at index 1.
> >> That's
> >> it. From there I see the following call chain
> >> QEventDispatcherGlib::processEvents() followed by emit awake() because
> >> canWait is false. I haven't traced it further. The signal emission
> >> doesn't
> >> have any consequence in the event loop though.
> > Can you check what happens when it calls into
> > QCoreApplicationPrivate::sendPostedEvents()? That function should loop
> > from
> > data->postEventList.startOffset to data->postEventList.size() (size at the
> > time you call into the function, so no new events wil be handed).
> > Like you said, it should be handled on the first iteration after it's been
> > queued.
> The problem is that my explicit calls to QCoreApplication::processEvents()
> do not reach QCoreApplicationPrivate::sendPostedEvents(). I found the root
Thanks for the detailed debugging, Richard, and for the bug report you filed.
Looks like I wasn't seeing the problem because I was looking at the UNIX event
dispatcher, but you're running against the Glib one. I usually prefer reading
the source of the former because I can scroll through all of it. With the Glib
one, since it goes through Glib and comes back out via callbacks, it's hard to
And that's exactly the problem: because of the need for callbacks, it's saving
the state for too long. There's a difference in behaviour between the two
dispatchers and that needs to be fixed.
> > It's not broken, that's why it's not deprecated. But that doesn't mean
> > it's a good API. It's not advisable to use nested event loops.
> > processEvents() is just the worst kind of nested event loops.
> Sure. Unfortunately, our application relies on QScriptEngine and requires
> that the engine's thread stays somewhat responsive. Now that I understand
> the problem, I might be able to implement a work-around in our application.
You may want QT_NO_GLIB=1 or just not build with Glib support.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Interest