DBusWatcher is a helper for RawDBusConnection. This patch moves
both classes into the same file. Calling RawDBusConnection::Watch
installs a DBusWatcher for the connection.
This patch removes the internal tasks from the implementation of
RawDBusConnection. All calls to RawDBusConnection are invoked on
the I/O thread, so the sender tasks only impose an overhead.
Currently DBusWatcher registers read and write watchers on
the I/O thread unconditionally. Thus for read-only DBusWatch
structures, the write watcher on the I/O thread generates a
significant amount of CPU overhead by constantly reporting
success via calls to OnFileCanWriteWithoutBlocking.
This patch changes DBusWatcher to respect the status flags
of supplied DBusWatch structures. It will only poll for
read or write status if the DBus watch has the corresponding
flag set.
DBus keeps track of these flags and calls the toggle callback
when it needs to wait on a certain DBusWatch.
This patch converts DBusWatcher to run on the I/O thread. When a
caller starts DBus, StartDBus creates a new connection and adds
it to the I/O thread's poll loop. DBusWatchers are created and
removed automatically by the DBus libary.
The I/O thread provides all features of the DBus thread. So most
of the existing code has been removed or rewritten. The former
includes the control socket and the DBus thread, the latter is in
the DBusWatcher code.
Using a private DBus connection gives each of its users, such as
Bluetooth, its own connection to the DBus server. This simplifies
the use of DBusWatch structures and ensures that all resources of
a connection are free'd when the connection gets closed.
Bluetooth maintains two connections to the DBus server and the DBus
system itself maintains a third one. This implies some overhead and
makes the code more difficult to understand.
This patch changes the Bluetooth code to use the connection that is
established by the DBus system.
DBusWatcher::Poll currently breaks after reading DBus data from the
socket. Thus, it never processes the data and dispatches the DBus
messages. This patch fixes the code to dispatch DBus messages after
reading the DBus socket.
This patch changes the DBus shutdown to only cleanup the DBus
thread from the main thread after DBusWatcher has completed.
This should ensure that the main thread will not have to wait
for the DBus thread.
--HG--
extra : rebase_source : 09ebb40a4e515ef5b0ebddfc1c3b7187cc546313
PollFdComparator, DBusEventTypes and flag conversion are only used by
DBusWatcher. This patch moves them into DBusWatcher's namespace.
--HG--
extra : rebase_source : 688403e55e139440e6d6d28e9802f8a48d7c355d
The Stop method encapsulates the code for sending the exit command
to a running DBus watcher.
--HG--
extra : rebase_source : 6963e6fa60b2e1e725046672a45cd325fc40a836
The DBus poll functionality is actually part of DBusWatcher. This
patch moves it to a class method.
--HG--
extra : rebase_source : 012813cf1d0967d6c29f7e085e49940570e1d58d
This patch renames DBusThread to DBusWatcher to make its purpose
more clear. Several callback functions for DBus are converted to
methods of DBusWatcher. Their POSIX calls are now protected by
TEMP_FAILURE_RETRY.
--HG--
extra : rebase_source : d8c6963aa8388c462917180d78e8e4289f9e987a
This patch cleans up the DBus utilitys and helper classes. All functions
for sending have been removed. Their users have been converted to the
new methods in RawDBusConnection. Include statements have been cleaned
up as well. Some methods of DBusMessageRefPtr have been moved from the
header to the source file to prevent inclusion of the DBus API from within
the header file.
This patch adds methods for sending DBus messages to the class
RawDBusConnection. There are 3 types of interfaces.
- Send Sends a message over DBus. No error checking or
handling of replies is performed. These methods
do not block the sending thread.
- SendWithReply Sends a message over DBus and runs a call-back
function for the reply. This should be the default
case for most scenarios. These methods do not
block the sending thread.
- SendWithError Sends a message over DBus and waits for the reply
or an error. This interface has only been added for
some existing code that can safely block the sending
thread. Don't use it in new code.
These 3 types of interfaces represent what is currently used of the
existing send functions in DBusUtils. When all users have been converted
to the new methods, the interfaces in DBusUtils can be removed.
For replacing the Bluetooth command thread with a LazyIdleThread,
we need to make sure that the DBus service thread is shutdown from
within the main thread.
This patch changes the DBus stop code to cleanup the DBusThread
structure from the service thread to prevent race conditions during
shutdown. The DBus service thread itself gets shutdown from the main
thread to fulfill the requirements of LazyIdleThread. The patch also
makes sure that it's not possible to accidently dispatch a runnable
while the DBus thread terminates.
RawDBusConnection incorrectly uses detail::RefCounted, which it
shouldn't. This patch converts it to use AtomicRefCounted instead.
--HG--
extra : rebase_source : 229bbbae3b43a47b362ab73dba5d1134a5ae1dac
Instances of RawDBusConnection can now be contained in nsRefPtr. This
allows to share the DBus connection among multiple threads.
--HG--
extra : rebase_source : fb24472b3b55e77abc7354f17ef679661f62b7fb
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.
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.
