Alex Riesen wrote:
I count 17 instances (excluding run_command). At least fetch-pack is not trivial (the sideband code. Could be done in a thread, which is not portable just as well).
I looked at that briefly a while ago -- at the prompting of a Windows developer friend of mine who has some interest in git -- and it seemed like the best thing for portability to non-fork()ing systems would probably be a refactor. It looked to me like it'd be possible to reorganize the code such that it'd work all in one process with no threads or forking or anything. Not *trivial*, mind you, but possible. There's nothing in the code path that I saw (I didn't analyze it super-thoroughly) that looked like it actually needed to run in parallel.
IMO it's worth doing at some point post-1.5.0 simply because it means one less hurdle for someone who's looking to port Git to Windows. Plus it'll probably make the code slightly more efficient even on Linux and friends; there'd be less context-switching latency.
From my brief look, that was the only nontrivial use of fork(). Almost all of the rest are simple fork/exec pairs.
Of course, the bigger hurdle for a native Windows port is all the shell scripts. Mercurial solves that by using Python for all its scripts, which at least has a native Windows version that can be installed. I wonder if git will/should eventually move its remaining shell scripts to Perl for that reason, Perl being git's de facto non-shell scripting language of choice.
-Steve - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html