Alex Riesen wrote: > Hmm... Could the allocation of large contiguous blocks also lock the > system hard? For instance, I avoid starting the test suite on my XP > workstation at work: it locks up hard every time. W2k works. > The system has nothing unusual in it. Well, it has an antivirus > program (which hopefully stopped working after a series of crashes, > which is just as well), an NVidia card with native driver (which is > broken in its own usual ways). Maybe that's enough In terms of the MSYS/Cygwin style of fork emulation, large memory allocations shouldn't pose any real problem, but they will be slow as the fork emulation has to manually replicate the state of the parent in the child and this means copying memory extents. (Yes, horribly ugly, no doubt about it, but it allows for porting.) This emulation code is sensitive enough that the Cygwin list has begun to maintain a list of software whose hooks/interference can cause Cygwin apps to fail: <http://cygwin.com/ml/cygwin-talk/2007-q3/msg00174.html>. Since MSYS is derived from the same code I see no reason why the list wouldn't also implicate potential problems with binaries linked to the MSYS runtime. Johannes Schindelin wrote: > We never had the problem in git itself, since we never used fork() on > Windows. The problem lies in our usage of bash and perl. > > Bash we can fix in the long run (this goes under the keyword > "builtinification" on the git list), but I do not see our reliance on Perl > going away, not for git {send-email,cvsimport,cvsexportcommit,svn}. > These are not too common operations, so common users will be able to do > without them. > > However, if you rely on the CVS/SVN connectors, or send-email, and in any > case in the short run, you better run Git on Windows only when that funny > Logitech driver is disabled ;-) Well, instead of using an MSYS build of Perl there's always ActiveState Perl. I think you may be stuck on the shell though -- I don't know of any ports of bash that aren't MSYS or Cygwin based. However I do think there's a native port of zsh out there by the GnuWin32 project, which when renamed as just "/bin/sh" might be suitable, but only if these scripts don't use bash-isms. I have not tried this zsh myself and speed/compatibility wise I'm not sure it's up to snuff. Brian - 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