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> |
||
---|---|---|
.. | ||
auto | ||
baselineserver | ||
benchmarks | ||
global | ||
manual | ||
shared | ||
README | ||
tests.pro |
This directory contains autotests and benchmarks based on Qt Test. In order to run the autotests reliably, you need to configure a desktop to match the test environment that these tests are written for. Linux X11: * The user must be logged in to an active desktop; you can't run the autotests without a valid DISPLAY that allows X11 connections. * The tests are run against a KDE3 or KDE4 desktop. * Window manager uses "click to focus", and not "focus follows mouse". Many tests move the mouse cursor around and expect this to not affect focus and activation. * Disable "click to activate", i.e., when a window is opened, the window manager should automatically activate it (give it input focus) and not wait for the user to click the window.