[Interest] Expected event execution order in this multi-thread application
Thiago Macieira
thiago.macieira at intel.com
Mon Sep 30 09:24:37 CEST 2019
On Sunday, 29 September 2019 22:51:57 PDT Richard Weickelt wrote:
> After debugging a bit, I come to realize that my above description is
> incorrect.
>
> - Thread T1 is handling an event E1
> - Thread T1 sends E3 to itself (queued connection)
> - Thread T2 sends an event E2 to T1 (queued connection)
> - Thread T1 handles E3 after completing E1.
> - Thread T1 while handling E3 calls QCoreApplication::processEvents()
> periodically
> - E2 is sitting in the event queue of T1 at the second position but gets
> never executed.
How do you know that? There's still a lack of synchronisation between T1
calling processEvents() and T2 posting the event. What if the event was posted
after you called it?
Anyway, DON'T use processEvents(). Redesign your code.
> I think my question was misleading. I am not so much interested in the order
> of arrival, but rather in "when" E2 gets executed by T1. I am fine with any
> arrival order and start of execution as long as
> QCoreApplication::processEvents() executes pending events while E3 is
> running. But that is not the case in above scenario. E2 is such a pending
> event, yet it doesn't get executed.
processEvents() does not process events posted after it started. It may want
for new timers and socket notifications, but not for new events.
> > The solution is to take a look at your threading code and see if you need
> > a
> > synchronisation.
>
> Sure, but I don't see a synchronization problem as long if
> QCoreApplication::processEvents() would do what the documentation says:
> executing pending events in the current thread. Am I misunderstanding
> something?
ALREADY pending events.
Anyway, this is when you should use processEvents(): never.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Interest
mailing list