On Mon, 2012-08-13 at 09:36 +0200, Patrick Ohly wrote:
> I double-checked. Debian's syncevo-dbus-server does use GIO D-Bus; what
> I saw must have been an indirect call to libdbus (happens later, via
> gvfs).
>
> > I think I got the same
> > issue with 1.2.99.4 (can't really check as I'm on vacation).
>
> I'll have another look.
Fixed on master branch. I now have an automated test case which
triggered the problem and a solution. This will be in 1.2.99.5 or 1.3,
whatever comes next.
It would be good to get this into Debian as a distro patch.
commit f7718ebb48bbd85b2b7eb29b45892ec20cbba0a2
Author: Patrick Ohly <patrick.o...@intel.com>
Date: Mon Aug 13 21:51:21 2012 +0200
D-Bus server + GIO D-Bus: fix auto-activation (Debian bug #599247)
When syncevo-dbus-server was started on demand by the D-Bus daemon,
then it registered itself with the daemon before it was ready to
serve requests. Only happened in combination with GIO D-Bus and
thus was not a problem before 1.2.99.x.
One user-visible effect was that the GTK UI did select the default
service when it was started for the first time, because it could not
retrieve that information from syncevo-dbus-server.
The fix consists of delaying the name acquisition. That gives the
caller a chance to register D-Bus objects first, before completing the
connection setup. The semantic change is that
dbus_bus_connection_undelay() must be called on new connections which
have a name (a NOP with libdbus).
This patch tries to minimize code changes. The downside of not
changing the GDBusCXX API more radically is that the bus name must be
attached to DBusConnectionPtr, where it will be copied into each
reference to the connection. Hopefully std::string is smart enough to
share the (small) data in this case. Should be solved cleaner once
libdbus support can be deprecated.
A test for auto-activation and double start of syncevo-dbus-server
is also added.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
