The method BluetoothDBusService::GetServiceChannel currently blocks the
Bluetooth command thread while waiting for a DBus message, before it
dispatches a runnable to the main thread.
With this patch, the DBus message is processed asyncronously, and the
runnable gets dispatched from the DBus reply handler.
--HG--
extra : rebase_source : 24519b7dd8d59fcbbf78436092610c8db195f6a2
Handler functions for DBus replies sometimes need several data fields
or need to keep state over replies for multiple messages. The DBus API
itself only allows for a single pointer to user data.
The class DBusReplyHandler is a base class for implementing DBus reply-
message handlers. Users of DBus can inherit from this class to implement
message-specific handlers.
--HG--
extra : rebase_source : 91c5f6e8d365922fd3b52fbaf502052f86274f16
The this commit moves the sending of blocking DBus messages to the
DBus thread. This allows us to avoid concurrency problems within the
DBus library, which is not explicitly thread-safe.
As a side note, I'd like to mention that blocking in distributed
systems simply doesn't work. The dbus library is especially broken
in this regard as it delays all unrelated messages until the reply
for the blocking request has been received. A future commit should
implement this functionality with an asyncronous call and make the
related thread wait for the reply.
The DBus send operation simply sends a DBus message without further
processing of replies. If the sender is interested in a reply, the
respective serial number can be returned. In this case, the sending
operation (and only the sending) is serialized with the calling
thread.
The class DBusConnectionSendWithReplyTask has been renamed to
DBusConnectionSendWithReplyRunnable, which better fits its purpose. The
internal callback function and data has been move into the implementation
of DBusConnectionSendWithReplyRunnable. Additionally, there is now an
abstract base class for DBus send runnables. This class will become useful
for implementing send classes with different policies.
This patch finally fixes bug 827888 were a message's reply was
received before the respective handler function could be installed.
The patch adds the class DBusConnectionSendWithReplyTask, which
asyncronously sends a DBus message and installs the reply's handler
function. The DBus utility functions for asyncronous messages create
an instance of this class and dispatch it to the DBus thread. This
intercepts the DBusPollTask, so no DBus replies can be received until
the dispatched DBusConnectionSendWithReplyTask has finished.
If a DBUS call completes before we can set the notifier function, the
call's response never gets handled. To workaround this problem, we now
call the notifier explicitly if the call completes this early.
It can still happen that the call's response gets lost, but this
workaround greatly improves the success rate for our problem of handling
errors during Bluetooth device pairing; from maybe 10% to 75%.
