libdbus has a bug where it doesn't notify the caller when a pending
method call failed because the connection went
down (https://bugs.freedesktop.org/show_bug.cgi?id=49728). ForkExec
relied on that to detect loss of connection.
Therefore a different method is needed to alert ForkExec. This commit
finishes the implementation of g_dbus_set_disconnect_function() and
provides a C++ binding for ForkExec.
Not calling dbus_server_disconnect() kept the socket open. The error
handling for trying different bus unix domain paths was also broke
(didn't reset the DBusError).
- moved common code into base class (prepare/send) reps. .cpp file (CheckError())
- retrieve D-Bus error description from error message and use it as part of
the C++ exception description, in addition to the error name (only error
name was used before)
- add call operators with up to 10 parameters
Added methods and classes for setting up direct D-Bus communication.
Only implemented for the non-GIO GDBus at the moment.
The callback must not throw exceptions because it is invoked from
plain C code.
DBusCallObject and friends were not used anywhere. Removed.
DBusObject and DBusRemoteObject used pure virtual methods to let
derived classes provide information about interface, path,
destination, method and the connection. The idea behind that was that
most of these strings are static and thus do not need to be copied.
The downside is that one had to derive from these classes in order to
provide the required information. The same class could not own two
instances of the generic DBusObject to access two different
destinations. It also sprinkled the code for setting up D-Bus
operations into several different places (constructor, class definition).
Now the information is passed to the DBus[Remote]Object constructor
and stored in the classes, which are thus merely containers for the
information and thus easier to use. Users of the classes still derive
from them, to keep the change smaller, although that is no longer
necessary.
Removed plain DBusConnection pointers from the C++ interface, return
DBusConnectionPtr instead. The exception is DBusObject, which still
returns plain pointers owned by the instance (as before) to ease
integration with the underlying D-Bus library. DBUS_CONNECTION_TYPE
is not needed.
This revealed that quite some code incorrectly took another reference
to the connection when assigning to DBusConnectionPtr (assignment
always increases the refcount, only in the constructor is that
optional). As a result the private connections were never
destructed. Apparently there were some global pointers to active
connections, so that this (minor) resource leak didn't show up in
valgrind.
It also showed that the closing of the D-Bus connection never happened
properly, although libdbus requires it. The ref counting mechanism
cannot be used for this because it cannot be checked whether the last
reference is about to be dropped. The slightly hackish solution is to
designate one DBusObject as the "main owner" of the connection. When
that object destructs, it closes the connection. There might still be
some other references; they simply cannot (and shouldn't) send or
receive messages anymore.
clang 2.9 is sensitive to the order of include statements when the
boost:: namespace is used. It happened to work with Bluez GDBus, but failed
with GIO GDBus.
Let's use the global namespace because it works in all case, although
the Boost documentation makes it sound like that the boost:: namespace
should be used.
Background: Prior to this patch a C++ wrapper around Bluez gdbus, a
convienience wrapper around the low-level libdbus, was used by
syncevo-dbus-server. This patch introduces a second C++ wrapper around
the GIO GDBus implementation. The reason for introducing this second
wrapper is to move away from using the in-tree copy of Bluez gdbus and
towards a more well-maintained dbus implementation. Also, libdbus was
not designed to be thread-safe whereas GIO GDBus was.
The GIO GDBus wrapper retains the same public api as the first
one. This means the consumers of this wrapper (syncevo-dbus-server,
for example) have remained almost completely untouched. The only
exceptions are in the few case where libdbus objects where used
directly by the consuming class.
The choice of which wrapper is determined at configure time. The
option can be explicitly set using the --with-gio-gdbus and
--without-gio-gdbus flags or, if no flag is given, an adequate version
of GIO is search for. If found, the GIO GDBus wrapper is chosen.
Somehow clang is sensitive to the order of definitions when using
boost::intrusive_ptr. This broke during the D-Bus server reorganization.
Putting the intrusive_ptr_* methods into the global name space instead
of boost works with clang and gcc and avoids the issue.
