On Mi, 2011-12-21 at 15:44 +0100, Patrick Ohly wrote: > On Mi, 2011-12-21 at 14:47 +0100, Patrick Ohly wrote: > > On Mi, 2011-12-21 at 14:17 +0100, Chris Kühl wrote: > > > Overall it looks like it makes sense. > > > > Good. I already went ahead and have a working implementation now, too. > > I pushed the complete implementation to the "fork-exec" branch. If (or > when ;-) you are working, please have a look at the changes. I'll not > rebase that branch anymore, feel free to use it as base of your work.
More changes pushed to "fork-exec": commit 075003d907a94e821189591bf36bff2b52a0d9ca Author: Patrick Ohly <[email protected]> Date: Mon Jan 9 14:40:34 2012 +0100 fork/exec: added state tracking ForkExecParent is now keeping track of the current state: IDLE, /**< instance constructed, but start() not called yet */ STARTING, /**< start() called */ CONNECTED, /**< child has connected, D-Bus connection established */ TERMINATED /**< child has quit */ Was needed for local sync and might be useful also elsewhere, thus implemented in the core fork/exec code itself. commit bf293d0b10e60d3c269a41b4f2b51aea0c54943b Author: Patrick Ohly <[email protected]> Date: Mon Jan 9 14:38:49 2012 +0100 fork/exec: implemented stop() and kill() Sending the signals was missing. > In the meantime I'll start rewriting the local sync to use D-Bus as > communication instead of the current fork+pipes. The downside will be > that local sync starts to depend on glib and D-Bus, which wasn't the > case before. More a theoretic problem, I don't think anyone really > needed local sync without also having (and using) the other two. I pushed my initial local sync with fork+exec to the "fork-local-sync" branch. Chris, do you want me to take a stab at adapting GDBus GIO to the recent GDBus libdbus changes (local D-Bus connection, API changes/improvements)? We also need to finalize the support for launching helper binaries. Here's what I do at the moment: commit 25db81431a7ac5c63ff40548c4b77ee68cfa9c8a Author: Patrick Ohly <[email protected]> Date: Mon Jan 9 16:36:28 2012 +0100 local sync: start 'syncevolution' as helper binary Must be done manually with a symlink called 'syncevo-local-sync'. A bit hackish at the moment and incomplete: how do we find the right "syncevolution"? Do we actually install symlinks or copies of the binary? Advantage of using 'syncevolution' instead of linking a separate helper: linking during compilation is slow. When static linking, the binaries become quite large (contain libsyncevolution). Disadvantage of using 'syncevolution': the D-Bus client code in syncevolution.cpp is dead code when running the helper. Minor issue?! What do you think about this? I prefer installing 'syncevolution' only once (i.e. no changes in the installation + packaging) and adding a "run binary xyz with argv[0] set to abc feature to fork/exec". The actual binary would be found by looking in these places: - SYNCEVOLUTION_BINARY env variable - argv[0] basedir of parent + "./syncevolution" - standard PATH That should take care of nightly testing (can set env variable if the other approaches fail), running inside "src" (because that's where all binaries reside in the build dir) and full installation. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
