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

[Thiago Macieira]

On Monday, 30 September 2019 01:33:12 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.

> > Anyway, this is when you should use processEvents(): never.
> 
> It is a public API and it is not marked as deprecated. If the function does
> not behave as documented, then either the documentation is wrong or the
> implementation has a bug or I am using it the wrong way. I don't think the
> latter is the case, but maybe I need a minimal test case to prove that.

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products