David Roundy <[EMAIL PROTECTED]> added the comment: On Fri, Nov 09, 2007 at 03:52:21PM -0000, Eric Kow wrote: > Is there any chance at all that Simon M's strict readFile would be > helpful here, adapted to FastPackedString? Or are they irrelevant > here, for example, because we are already doing something like it?
Actually, we almost always read strictly (and then close the file handle). The only time we don't is when we try to read patches lazily (or use mmap), so somehow we must be reading these patches lazily. Now that I think about it, mmap probably isn't a problem, because we only mmap rather large files that haven't been gzipped. So perhaps just eliminating the lazy reading of patches will solve our problem. > Another question: maybe instead of failing to close handles, could > there be such a problem as opening handles long long before we > actually try to read from them? This shouldn't happen, as long as we're reading the patches strictly. I think we ought to be go ahead and do this, to simply read all patches strictly. Ian put a lot of work into *removing* the strict reading of patches, so that we wouldn't need to hold entire patch files in memory, but in practice noone uses darcs with patches that don't fit into memory, and many people use darcs with many small patches, so we should optimize for the latter case. If everything worked right, we could work in both cases, but that's not currently the case, if it ever was. The trick is that lazy reading of patch files means we don't close them until we've "used" the entire patch, and then only if the parser reads the entire file, to the bitter end. We might also simplify the patch parsing code ReadMonad and all that, by removing the whole lazy parsing concept. Simpler code is easier to verify is bug-free, and also makes it easier to reason about space/time behavior. Of course, it could be that this is just the bug that you already fixed in the lazy reading code, in which case we could perhaps close this ticket... although improving the error message (as suggested by reporter) would also be good. -- David Roundy Department of Physics Oregon State University ---------- title: pull => resource exhausted (Too many open files) (1.0.9) -> Getting source code __________________________________ 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
