Re: [SyncEvolution] syncevo-dbus-server + forking processes

On Mon, Jan 9, 2012 at 4:54 PM, Patrick Ohly <patrick.ohly(a)intel.com&gt; wrote: > commit bf293d0b10e60d3c269a41b4f2b51aea0c54943b > Author: Patrick Ohly <patrick.ohly(a)intel.com&gt; > 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 <patrick.ohly(a)intel.com&gt; > 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

> 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.