0d75f8e95a
The explanation is in the code comment. Ever since QDBusConnections began being processed in a separate thread, we were relying on the fact that the main thread didn't begin processing its event queue until the second event got posted (the event loop only exits after it has finished processing all pending events). We had a race between the main thread starting its processing, at which point it decides which is the last event it will process, and the QDBusConnectionManager thread posting the second event. This is very fragile code, since it depends on the behavior of QDBusConnectionPrivate (how it stores the signal relays in a hash) and that of QHash with duplicate keys. This only works because the hash key between the two connections is the same (it's only dependent on the method name and interface name). If we ever begin using something that isn't the same between "control" and "p", then with QHash's randomness, we'll be racy again. Change-Id: I42e7ef1a481840699a8dffff1406c3a4674ec3a6 Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com> |
||
---|---|---|
.. | ||
qdbusabstractinterface | ||
qpinger | ||
interface.cpp | ||
interface.h | ||
org.qtproject.QtDBus.Pinger.xml | ||
qdbusabstractinterface.pro | ||
tst_qdbusabstractinterface.cpp |