[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