On Saturday, 5 October 2019 06:13:56 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. > > The problem is that my explicit calls to QCoreApplication::processEvents() > do not reach QCoreApplicationPrivate::sendPostedEvents(). I found the root > cause: [snip]
Thanks for the detailed debugging, Richard, and for the bug report you filed. Looks like I wasn't seeing the problem because I was looking at the UNIX event dispatcher, but you're running against the Glib one. I usually prefer reading the source of the former because I can scroll through all of it. With the Glib one, since it goes through Glib and comes back out via callbacks, it's hard to follow. And that's exactly the problem: because of the need for callbacks, it's saving the state for too long. There's a difference in behaviour between the two dispatchers and that needs to be fixed. > > 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. > > Sure. Unfortunately, our application relies on QScriptEngine and requires > that the engine's thread stays somewhat responsive. Now that I understand > the problem, I might be able to implement a work-around in our application. You may want QT_NO_GLIB=1 or just not build with Glib support. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest