On Mo, 2011-11-28 at 18:00 +0100, Chris Kühl wrote: > On Wed, Nov 16, 2011 at 2:39 PM, Patrick Ohly <patrick.o...@intel.com> 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. -- 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 SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
