On Tue, Dec 20, 2011 at 2:23 PM, Patrick Ohly <[email protected]> wrote: > On Mo, 2011-12-19 at 10:57 +0100, Chris Kühl wrote: >> On Fri, Dec 16, 2011 at 3:41 PM, Patrick Ohly <[email protected]> wrote: >> > 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. > > Attached is a first API proposal for the fork/exec helper class and how > it could be used in a small test program. Does that look sane? > > I haven't started implementing any of the new methods, but it should be > fairly straightforward (famous last words). >
Overall it looks like it makes sense. A couple questions though. * Where would you be using g_child_watch here? I'm assuming it would be set up internally in ForkExecParent and then trigger the OnQuit signal. * Should the forkexec argument set opt_fork_exec rather than opt_server. * Is there a way to avoid passing in the MainLoop? Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
