On Tue, Nov 29, 2011 at 8:40 AM, Gapps + local IMAP <[email protected]> wrote: > On Mo, 2011-11-28 at 18:00 +0100, Chris Kühl wrote: >> On Wed, Nov 16, 2011 at 2:39 PM, Patrick Ohly <[email protected]> wrote: >> > 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. > > Please also add an env variable which overrides that default location. > The nightly testing needs that because it runs with an installation that > was made with DESTDIR and thus doesn't have the files in the hard-coded > places. > >> > 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. > > Duh, of course. > > [fork + function call from main()] > >> 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. > > Your concerns mirror my own concerns, so agreed, let's do the fork+exec. >
Ok, I'll proceed in that direction and post a more detailed plan once I do a little more poking. Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
