David Roundy <[EMAIL PROTECTED]> added the comment: On Thu, Nov 08, 2007 at 07:44:15PM -0000, Richard Giraud wrote: > After doing some investigation, this appears to the be result of OS X > limiting > the number of files that a process can have open. Increasing this limit > makes > the issue disappear. > > By default, user accounts are limited to 256 open files (per process?) but > this can be changed with ulimit. To see the current limit, type in > `ulimit -n'.
Yikes! On linux this value is 1024, which I'm sure is why this hasn't been seen before. > To increase the allowed number of files to the maximum, type in `ulimit -n > unlimited'. Sometimes an error message will be generated, sometimes not. > If a message is generated, restart Terminal.app and try again. After the > operation succeeds, it's probably a good idea to set the limit back to its > original value (`ulimit -n 256'). > > After doing some testing, it appears that 256 files is only slightly too > small; `darcs pull -a' succeeds (at the moment) when the file limit is set > to 320. This bug shouldn't manifest itself if you recompile darcs with --disable-mmap. Could you check this? If it's too much trouble, I'll completely understand, but it'd be helpful for us. Perhaps we should give up on using mmap by default? Obviously we're holding all the patch files open, and my guess is that this is because they are mmapped. There are two fixes for this: we could disable mmap, or we could make the code not require that all those patches be in memory at the same time. The latter fix is trickier and more fragile (in the sense of easier to break by making a small change in the code), but has the advantage of also reducing memory usage and increasing speed. Of course, we don't want to hold mac users hostage in order to give ourselves greater motivation for making even better improvements. Using mmap *is* a win under memory pressure, and just in general it should provide faster IO. So it'd be nice to not disable it. We could also figure out how to query the number of available file handles and dynamically check and stop using mmap when we approach the limit, but that sounds both complicated and fragile. > This may also be applicable to issue87, issue 135, issue478. Thanks for looking these up! > I set the priority to bug because I couldn't add this info without doing so. I think "bug" is reasonable. If you were doing something insane, then this wouldn't be a bug, but pulling three hundred patches at once is definitely reasonable use of darcs. -- David Roundy Department of Physics Oregon State University __________________________________ Darcs bug tracker <[EMAIL PROTECTED]> <http://bugs.darcs.net/issue560> __________________________________ _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
