On Mon, Dec 5, 2011 at 2:12 PM, Patrick Ohly <patrick.o...@intel.com> wrote: > On Mon, 2011-12-05 at 12:12 +0100, Chris Kühl wrote: >> On Wed, Nov 16, 2011 at 12:22 PM, Patrick Ohly <patrick.o...@intel.com> >> wrote: >> > Here are some requirements for "sync in forked process": >> > * should be disabled when running outside of the D-Bus daemon >> > (syncevolution command line in non-daemon mode, client-test >> > testing) >> >> This seems pretty straightforward because when in non-daemon mode none >> of the src/dbus/server code is touched anyway. I'm hoping to disturb >> the code in src/syncevo as little as possible. But I've not touched >> src/syncevolution.cpp much so maybe I'm missing something. > > Yes, this should work. libsyncevolution (aka src/syncevo) communicates > with the front-end via ConfigUserInterface (implemented differently for > command line and D-Bus server) and several virtual methods in > SyncContext (display*(), for example displaySyncProgress()). > > In particular the password request mechanism is very convoluted. I > haven't written that part myself and each time I look at it, I need to > trace through the various methods before I can piece together how they > interact. > > I suspect that this will have to be cleaned up. Perhaps SyncContext > should be parameterized with instances of ConfigUserIterface and > SyncUserInterface (new class, would hold the display* functionality) > instead of deriving from it? > >> > * interactive password requests through D-Bus must continue to >> > work >> > * abort/suspend requests via D-Bus must work >> > * the forked process should shut down cleanly, so that "valgrind >> > --follow-child=yes --leak-check=yes" provides sane results (the >> > forked process in a local sync currently fails to do that, >> > because it is forked in a less controlled environment and >> > therefore just calls _exit()) >> >> Using fork then exec should mostly relieve us of this issue. > > Agreed. > >> > * logging: >> > * the main syncevo-dbus-server process should use syslog >> > logging for its own messages, without redirecting >> > stdout/stderr >> > * the forked process should start redirecting >> > stdout/stderr into the normal logging mechanism (so that >> > library error messages are visible when running the >> > syncevolution command line as client of the D-Bus server >> > and, later, they appear in log files) and switch to a >> > session log when the session is ready >> > >> >> I plan to do this work in 3 steps: >> >> 1) The first step, which I've started, is to decouple the session and >> server from each other and also modify objects that require both the >> session and server objects as needed. Once this is done the server >> should function as it does now and all tests should pass in order to >> move on to step 2. >> 2) Move session into separate binary using a one-to-one dbus >> connection for communicating between the 2 processes. At this stage >> only one session is run at a time and all tests should pass as before. > > Please try to keep this flexible. I'd like to use the separate binary > not only for running sessions, but also for monitoring local and remote > databases for changes. The main D-Bus server then would get a signal > that a specific config requires a sync run and would kick of that > operation when suitable. >
When you say 'flexible' I'm assuming you are referring to both the means by which a new process is spawned and how the communication channel (peer-to-peer dbus connection) is set up. I'll try to wrap this up in a way that you can easily make use of it. >> 3) Enable running multiple concurrent sync sessions. At this stage >> we'll probably need to add/modify some tests in order to deal with the >> new functionality. > > Multiple concurrent sync sessions are a can of worms, so careful here. > The main question is: which sync sessions are allowed to run in > parallel? > Yes, I was wondering how such resource contention should be dealt with. > For example, syncing against the same local database in parallel is > asking for (unnecessary) trouble. If the instance controlling sync > sessions wants to prevent that, how does it identify the "same > database"? Backend "foo" + database "xxx" might access the same data as > backend "bar" + database "yyy" (in theory, at least). > > The original idea was that each database would only be configured once, > so that source "addressbook" in context "@default" would be unique. But > this has never been enforced (it can't be, due to the problem above) and > has not been clearly documented either. > Ideally we'd be able to detect a unique source and build a source blacklist based on the already running syncs. If a sync wants to use a source that is already being used *and* that source is not able to handle concurrent syncs reliably then it gets placed in a queue until a running sync finishes. At that point the blacklist is updated and the waiting sync is checked again. We've got a little bit of time to think about this one. I'll see what I can come up with along the way. Cheers, Chris _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
