Are Haskell folks satisfied with the practical necessity of imperatively & explicitly reclaiming resources such as file handles, fonts & brushes, video memory chunks, etc? Doesn't explicit freeing of these resources have the same modularity and correctness problems as explicit freeing of system memory (C/C++ programming)?
I wrote a lovely purely functional graphics library that used video memory to lazily compute and cache infinite-resolution images, and I found that I don't know how to get my finalizers to run anytime soon after video memory chunks become inaccessible. Explicit freeing isn't an option, since the interface is functional, not imperative (IO). I guess I'm wondering a few things: * Are Haskell programmers generally content with imperative and bug-friendly interfaces involving explicit freeing/closing of resources? * Do people assume that these resources (or handling them frugally) aren't useful in purely functional interfaces? * Are there fundamental reasons why GC algorithms cannot usefully apply to resources like video memory, file descriptors, etc? * Are there resource management techniques that have the flexibility, efficiency, and accuracy of GC that I could be using for these other resources? Thanks, - Conal 2008/4/14 Abhay Parvate <[EMAIL PROTECTED]>: > Hello, > > In describing the Handle type, the GHC documentation says (in the > System.IO documentation): > > GHC note: a Handle will be automatically closed when the garbage collector > detects that it has become unreferenced by the program. However, relying on > this behaviour is not generally recommended: the garbage collector is > unpredictable. If possible, use explicit an explicit hClose to close Handles > when they are no longer required. GHC does not currently attempt to free up > file descriptors when they have run out, it is your responsibility to ensure > that this doesn't happen. > > But one cannot call hClose on Handles on which something like hGetContents > has been called; it just terminates the character list at the point till > which it has already read. Further the manual says that hGetContents puts > the handle in the semi-closed state, and further, > > A semi-closed handle becomes closed: > > - if hClose is applied to it; > - if an I/O error occurs when reading an item from the handle; > - or once the entire contents of the handle has been read. > > So do I safely assume here, according to the third point above, that it's > fine if I do not call hClose explicitly as far as I am consuming all the > contents returned by hGetContents? > > Thanks, > Abhay > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe