Alex Riesen wrote:

quoted text
> 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:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html