On Fri, Dec 16, 2011 at 3:41 PM, Patrick Ohly <patrick.o...@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 [1]. > > 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 when > 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. Cheers, Chris _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
