On Wed, Nov 16, 2011 at 12:22 PM, Patrick Ohly <[email protected]> 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)
> * 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())
> * 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
>
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 that
> 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 [1], 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.
[1] https://bugs.meego.com/show_bug.cgi?id=23762
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
