From: Linus Torvalds Date: Sat, 24 Sep 2005 02:46:47 GMT Subject: Re: git 0.99.7b doesn't build on Cygwin Message-ID: In-Reply-To: On Sat, 24 Sep 2005, Johannes Schindelin wrote: > > BTW I am fairly convinced that the same issues would trouble a git-pull, > once the networking is running, since the pack transfer relies on > fork()ing. I'm not sure. Almost all other fork() users end up doing a more-or-less immediate execve() after the fork. Yes, they do some other minor setup, but not a whole lot. The diff.c fork() is somewhat different. It actually ends up doing malloc and stdio IO before it actually gets to the exec(), so that one is more likely to hit any bugs in the fork() implementation. Actually, looking a bit closer, the create_pack_file() thing also does malloc inside the child, but at least there it would be trivial to move that argument setup code into the parent. But looking at send_pack() or fetch_pack(), for example, they are both _very_ traditional fork()+exec() calls, with just a few close() calls in between. Looking a bit closer at the diff() usage, I actually think that we could move the fork() closer to the exec - we'd just have to move it _into_ all the different cases (ie you'd have two different fork() calls: one for the "builtin" case, one for the external pgm case, but then the child in both cases would be very simple). Oh. Actually, I wonder if we could mke them "vfork()" calls. Does anybody know if cygwin has an easier time with vfork() + eventual exec? That _should_ map better to a non-UNIX process model, so maybe we could do it that way? > It sure would be nice to have a unified diff generator included, but I > doubt that a reliable (=simple) one is easy to come by. Yeah, I looked at GNU diffutils, and I had to rinse out my eyes with soap and water. Linus