On Wednesday 15 April 2015 16:45:57 Thiago Macieira wrote: > Hello > > We're running into problems with QCoreApplication::notify() and auxiliary > threads in Qt. Details can be found in [1] and [2].
> [1] http://lists.qt-project.org/pipermail/development/2015-April/021053.html > [2] https://codereview.qt-project.org/110325 Thanks to all that replied. The solution being implemented can be seen in https://codereview.qt-project.org/110643 It's private API only, so it will not affect your current uses of QCoreApplication::notify(), unless you're trying to catch events from Qt's own threads. The solution I'm implementing will make it so Qt's own threads do not go through QCoreApplication::notify(). However, be advised that you need to ensure ALL threads stop delivering events before your application object begins destruction. That includes threads you did not directly start, but were started on your behalf inside other libraries (and anywhere I didn't catch in Qt). If you can't guarantee that, stop overriding notify() -- there's no other possible solution. This is not a new requirement. It's been there since Qt 3.0, but no one noticed until now. It is undefined behaviour[*] if you fail to do that. For that reason, Qt 6.0, whenever that happens, will stop calling notify() outside the main thread. In Qt 5.0, we did that for event filters installed in the main application. See the notices in https://codereview.qt-project.org/110644 [*] understand "undefined behaviour" in the C++ standard terms: *anything* can happen, from nothing to defrosting your fridge to launching a nuclear attack. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
