On Wed, Nov 16, 2011 at 2:39 PM, Patrick Ohly <[email protected]> wrote: > 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? >
Yes this was going to be my proposal. > 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? I believe the place for the "helper" sync binary would be in the libexec directory: /usr/libexec/syncevolution/sync-session for example. How does injecting valgrind into the new > binary work?) Valgrind can follow child processes with --trace-children=yes and create a log-file per process by inserting %p in the log-file name. and a bit more expensive (must load all libraries again). > This will definitely require a small bit more resources to be used and take a few microseconds longer to start but these are resources that will be mostly loaded from memory (and probably cache) after the first sync session is started and be freed when the process disappears. Also, the time a fork-exec pair takes over just a fork is insignificant compared to how long a sync session takes. > 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), The potential problem I see is that some of the resources we may not be able to free because they are not under our control: libraries, etc. then go down a > different path as if the binary had just been started. > This is how I originally intended to implement this till I started looking into it a little more and asking around. To me, the potential problems seem to outweigh the advantages. Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
