On 1/4/07, Norman Ramsey <nr@eecs.harvard.edu> wrote:
There seems to be a misunderstanding here: readFile in itself is not the solution. readFile is defined thus:
readFile name = openFile name ReadMode >>= hGetContents
and the original code was this:
load fn = do handle <- IO.openFile fn IO.ReadMode contents <- IO.hGetContents handle IO.hClose handle return $ XP.xmlParse fn contents
Sure, you can replace the openFile/hGetContents pair by readFile, but the real problem is the presence of the hClose. Removing that will solve your problem (but note that you now have no control over when the file is actually closed).
Can I just leave it hanging and rely on the garbage collector to close it in the fullness of time?
Actually, hGetContents closes the handle when it gets an EOF. If it never does get EOF (because you never use all of the data), the garbage collector *might* close the handle, but I haven't heard of a garbage collector that was aware of the value of resources other than RAM (that is, they don't go out of their way to run finalizers and free up handles to OS resources). Java has the same problem, though I'm not sure if its file handles *have* finalizers, and Python does too, except the refcounting in CPython right now hides it.