[Interest] Expected event execution order in this multi-thread application

[Thiago Macieira]

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
> cause:
[snip]

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 
follow.

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