On Mon, Jan 9, 2012 at 4:54 PM, Patrick Ohly <[email protected]> wrote: > 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. >
I've got a commit which adds a getChildPid() method to ForkExecParent in my branch. I'm using this as a quick and dirty unique idea that the server and child session share right now. > 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. For my part, I've been moving forward with attempting to place the session and connection objects into the helper binary. The public dbus interface still must reside in the server process in order to keep the path and objects on the same name (org.syncevolution). So, most session information is relayed from the helper process to the server process via the p2p dbus connection. My thinking is that this simplifies the server and would make it easier to eventually get rid of the g_main_loop manipulation that's prevalent now. I'm not 100% convinced this will work in the end. Do you see any show-stopper to this approach? > > 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)? > In order to avoid distraction, I was intending to do this only once concurrent session is working with the libdbus implementation. However, I can see that if you want to go ahead and merge you local sync code into master that would need to be done first. So, feel free to do that. > 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. On the other hand, if you make changes only in code that the helper depends on then the server lib doesn't need to be recompiled. When static linking, > the binaries become quite large (contain libsyncevolution). > To give this some numbers... using --disable-shared --enable-static the binary sizes are: -rwxrwxr-x. 1 chris chris 27M Jan 9 18:16 syncevo-dbus-helper -rwxrwxr-x. 1 chris chris 32M Jan 9 18:16 syncevo-dbus-server using --enable-shared --disable-static it's: -rwxrwxr-x. 1 chris chris 8.7K Jan 9 18:28 syncevo-dbus-helper -rwxrwxr-x. 1 chris chris 8.6K Jan 9 18:28 syncevo-dbus-server > Disadvantage of using 'syncevolution': the D-Bus client code in > syncevolution.cpp is dead code when running the helper. Minor issue?! > Yes, minor I'd say. > 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 > I like the cleanliness of the separate binary myself. And actually I'm already using a separate binary in my branch[1]. I guess when you said "I'd like to use the separate binary..."[2] I took that as a green light to build a separate binary. ;) I can change that if you insist, though. > 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. > Cheers, Chris [1] https://meego.gitorious.org/meego-middleware/syncevolution/commit/fc88b735c86193e051b12d337aaf322759b85585 [2] http://lists.syncevolution.org/pipermail/syncevolution/2011-December/003227.html _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
