On Mo, 2011-11-28 at 18:00 +0100, Chris Kühl wrote:
On Wed, Nov 16, 2011 at 2:39 PM, Patrick Ohly
> No, that's what I was looking for. When you say "command line
> 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
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
> 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.