diff options
author | Thiago Macieira <thiago.macieira@intel.com> | 2015-12-27 11:15:24 -0200 |
---|---|---|
committer | Thiago Macieira <thiago.macieira@intel.com> | 2016-01-02 02:05:45 +0000 |
commit | 1f6fa1f37a14742ddf53c753ce52d9dc048cd1dc (patch) | |
tree | bdd3f7853503e2eec824f951a0236b7571c504c0 /src/dbus/qdbusconnection_p.h | |
parent | 8d195c0d57ea241183d23c45f855be1b126d8ee7 (diff) | |
download | qtbase-1f6fa1f37a14742ddf53c753ce52d9dc048cd1dc.tar.gz |
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 'src/dbus/qdbusconnection_p.h')
-rw-r--r-- | src/dbus/qdbusconnection_p.h | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/src/dbus/qdbusconnection_p.h b/src/dbus/qdbusconnection_p.h index 2df7a49966..f030a3ff8c 100644 --- a/src/dbus/qdbusconnection_p.h +++ b/src/dbus/qdbusconnection_p.h @@ -169,6 +169,7 @@ public: // typedefs typedef QMultiHash<int, Watcher> WatcherHash; typedef QHash<int, DBusTimeout *> TimeoutHash; + typedef QVector<QDBusMessage> PendingMessageList; typedef QMultiHash<QString, SignalHook> SignalHookHash; typedef QHash<QString, QDBusMetaObject* > MetaObjectHash; @@ -191,6 +192,7 @@ public: ~QDBusConnectionPrivate(); void createBusService(); + void setDispatchEnabled(bool enable); void setPeer(DBusConnection *connection, const QDBusErrorInternal &error); void setConnection(DBusConnection *connection, const QDBusErrorInternal &error); void setServer(QDBusServer *object, DBusServer *server, const QDBusErrorInternal &error); @@ -308,6 +310,7 @@ public: }; WatcherHash watchers; TimeoutHash timeouts; + PendingMessageList pendingMessages; // the master lock protects our own internal state QReadWriteLock lock; @@ -322,6 +325,7 @@ public: PendingCallList pendingCalls; bool anonymousAuthenticationAllowed; + bool dispatchEnabled; // protected by the dispatch lock, not the main lock public: // static methods |