summaryrefslogtreecommitdiffstats
path: root/tests/auto/dbus/qdbustype/qdbustype.pro
diff options
context:
space:
mode:
authorThiago Macieira <thiago.macieira@intel.com>2015-12-27 11:15:24 -0200
committerThiago Macieira <thiago.macieira@intel.com>2016-01-02 02:05:45 +0000
commit1f6fa1f37a14742ddf53c753ce52d9dc048cd1dc (patch)
treebdd3f7853503e2eec824f951a0236b7571c504c0 /tests/auto/dbus/qdbustype/qdbustype.pro
parent8d195c0d57ea241183d23c45f855be1b126d8ee7 (diff)
Suspend processing of some messages in the default busses by default
To retain a bit compatibility with applications developed in the last 9 years that expect that QDBusConnections won't process their events until the event loop runs, we now suspend the handling of incoming messages in the two default buses (and only in them) and resume when the event loop starts. This is required because the new threaded QtDBus would otherwise process incoming messages that the application didn't expect it to. For example, if the application first acquires names on the bus and only after that registers objects with QtDBus, there's a small window in which the name is acquired and visible to other applications, but no objects are registered yet. Calls to those objects may be received, would then be processed in the QDBusConnectionManager thread and fail. The work around is to disable the actual handling of method calls and signals in QDBusConnectionPrivate::handleMessage. Instead, those messages are queued until later. Due to the way that libdbus-1 works, outgoing method calls that are waiting for replies are not affected, since their processing does not happen in handleMessage(). [ChangeLog][Important Behavior Changes] QtDBus now uses threads to implement processing of incoming and outgoing messages. This solves a number of thread safety issues and fixes an architectural problem that would cause all processing to stop if a particular thread (usually the main thread) were blocked in any operation. On the flip side, application developers need to know that modifications to a QDBusConnection may be visible immediately on the connection, so they should be done in an order that won't allow for incomplete states to be observed (for example, first register all objects, then acquire service names). Change-Id: I39cc61d0d59846ab8c23ffff1423c6d555f6ee0a Reviewed-by: David Faure <david.faure@kdab.com>
Diffstat (limited to 'tests/auto/dbus/qdbustype/qdbustype.pro')
0 files changed, 0 insertions, 0 deletions