On Mo, 2012-01-09 at 18:59 +0100, Chris Kühl wrote: > On Mon, Jan 9, 2012 at 4:54 PM, Patrick Ohly <[email protected]> wrote: > > 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?
The main syncevo-dbus-server definitely should get rewritten that it is completely asynchronous and runs g_main_loop() only once. Anything that runs a sync session (i.e. the helper) will have to continue doing the g_main_loop dance or become multithreaded, because the libsynthesis APIs are not asynchronous. I'm not sure which of the two is the lesser evil: multithreading or entering/leaving the main loop repeatedly. > > 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. Okay, will do. > > 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. True. > 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 I wouldn't want that kind of code duplication in a production version, but as this is just for development I don't think it matters. My concern about link times is also unfounded - at least on my new laptop ;-) 3 seconds to link is fine. It used to be longer. > > 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. No, let's do it with separate binaries. I'll follow suit with local sync. -- 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
