On Mi, 2011-11-16 at 13:55 +0100, Chris Kühl wrote:
> On Wed, Nov 16, 2011 at 12:22 PM, Patrick Ohly <[email protected]> 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)
> > * 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.
I know, that's why I'd rather discuss this upfront. Some of these
requirements are implied by "change must not cause
regressions" (interactive passwords, abort/suspend), others are open
questions (startup/shutdown of the forked process, logging).
> > 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],
There are no more specific plans yet.
> 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.
No, that's what I was looking for. When you say "command line argument",
does that mean that there will be an exec() involved? Would that start
the same binary or something else?
The advantage of the exec() is that the new process is much cleaner. The
downside is that it is harder to implement (How does the forking process
find the "right" executable? How does injecting valgrind into the new
binary work?) and a bit more expensive (must load all libraries again).
It might be easier to avoid the exec() and instead return to main() of
the syncevo-dbus-server in the forked process (including freeing of all
parent process resources, which must be done anyway), then go down a
different path as if the binary had just been started.
--
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
