On Wed, Nov 16, 2011 at 12:22 PM, Patrick Ohly <patrick.o...@intel.com> wrote: > Hello! > > Chris is going to work on running syncs inside a process forked from the > main syncevo-dbus-server. Before diving into the planning and > implementation, let me outline the background. > > At the moment, syncevo-dbus-server is one process (when ignoring local > sync for a second) which handles D-Bus calls and syncs at the same time. > A sync involves operations which can block for a long time, so keeping > the D-Bus part alive and responsive is challenging. It involves hacks > like entering and leaving the main event loop, checking it inside > libsoup, etc. > > Local sync already uses a second forked process so that it can run > client and server engines concurrently. > > Getting rid of the current hacks is one motivation for running syncs in > a forked process. The main process would enter the main loop once and > never return unless it was asked to shut down. > > The other is that (eventually) it'll allow to run a "clean" main process > which never loads any of the backend modules. That may help to keep the > permanent memory footprint smaller than it is today. Right now this is > not possible because merely registering a backend requires loading it. > Fixing that is outside of the current scope. > > Resource leaks inside a sync become less problematic when the process > running the sync can shut down. > > 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. > * 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. > * 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. 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. Cheers, Chris _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
