On Fri, Dec 16, 2011 at 3:41 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mi, 2011-12-14 at 16:52 +0100, Chris Kühl wrote:
> I just looked but don't see anything. If you are referring to setting
> up a peer-to-peer dbus connection, that's done using the (G)DBusServer
> class. There is an example at .
I have that same example working based on GDBus + libdbus. What I don't
like about it is that the connection is based on listen() + connect().
This makes it harder for the parent to detect that the child died: if
the parent did the usual trick (create socket pair, fork+exec child,
close its own side of the socket pair), then a closed socket would
indicate that the child died. With listen() + connect() it has to check
for existence of the child periodically. SIGCHILD does not integrate
into the main loop well, but I see that g_spawn() has a GChildWatch -
that should do.
Yes, looking at the source for the GChildWatch related code it blocks
SIGCHLD. When the mainloop's worker routine is run it checks if any of
the blocked signals are pending and then iterates over the
GChildWatchSources checking if the process has exited. So by checking
the return value of g_spawn_async_with_pipes and setting up the
GChildWatch I don't see a way to miss the childs exit, either.
While working on this I got unhappy with some aspects of the current
D-Bus C++ wrapper. The result is the "dbus-cleanup" branch. Chris, what
do you think about that?
This looks fine. Moving the connection info to DBusObject definitely
makes sense and reduces the code a bit. And, yes, I should have made
better use of DBusConnectionPtr.
Note that your example code closed the
connection while the rest of SyncEvolution didn't. This might be
something that still needs to be fixed.
It seems that this is dependent on how the connection was created. Let
me take a look at this more closely.
While testing that with GDBus GIO I noticed that I get segfaults
compiling on Debian Testing and --with-gio-dbus. That happens with and
without my clean up patches - Chris, can you check that? If you cannot
reproduce it, then please let me know and I will check it. It's a bit
strange that I haven't seen that in the nightly testing.
The signal callback seems to get an invalid std::string:
My testing involved running the test-dbus.py script. I guess this
didn't cover all cases. I'll look into this as well.