On Wed, Nov 16, 2011 at 12:22 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
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
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
* interactive password requests through D-Bus must continue to
* 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())
* the main syncevo-dbus-server process should use syslog
logging for its own messages, without redirecting
* 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
Thanks for the list of requirements. I'll take these into
consideration. Some in there that we hadn't talked about before.
Somewhat related to this work is support for push sync. I suspect
this will also use forked processes to monitor remote and local
databases without interfering with the main process. It would be good if
the mechanism for forking and communication between process was generic
and not tied to syncing alone.
I'm not really well informed on the plans for push sync other that
what I found in , but the idea that I had in mind was for the
forking process to initiate a d-bus peer-to-peer ("one-to-one" in the
d-bus spec) connection by forking the process with the d-bus address
as a command line argument. The client then uses that for
communication. This seems pretty generic to me. The only differences
would be the d-bus interface used. ...but maybe I'm misunderstanding
what you mean.