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.
The new function allows to schedule nsRunnables to an existing DBus
thread. This intercepts the running instance of DBusPollTask and
makes the DBus thread process the dispatched runnable. The intercepted
poll task automatically continues polling once all pending runnables
have been processed.
This patch replaces the DBus EventLoop function by an instance
of DBusPollTask. It also cleans up the initialization and shutdown
code of the DBusThread.
This patch adds class DBusPollTask. The DBusPollTask class is an
nsRunnable for receiving DBus messages. It is intended to run in
a separate thread that is dedicated to DBus only.
The Run function of the poll task resembles the DBus EventLoop
function, but allows to intercept execution in favor of other
nsRunnables. Afterwards the DBusPollTask continues.
We intent to run the DBus thread's EventLoop function as separate
nsRunnable, but the function also contains code for initializing
sockets that are used for internal communication.
With this patch the socket initialization has been moved to the
setup function. This reduces the EventLoop function to plain event
handling.
There were merges in configure.in and some Makefile.in. None had any
conflicts. I spot verified the Makefile.in changes and confirmed that
the changes did not touch any DIRS* variables.
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%.
