[Interest] Expected event execution order in this multi-thread application
thiago.macieira at intel.com
Mon Sep 30 16:43:38 CEST 2019
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
> > 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
More information about the Interest