[Interest] Survey: do you override QCoreApplication::notify? Why?

[Thiago Macieira]

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