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 _______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
