Hello Abhay, Wednesday, April 16, 2008, 9:30:34 AM, you wrote:
i think it will not work with current ghc GC - it scans entire memory/nursery when garbage collected so anyway you will need to wait until next GC event occurs > Your mail gives me an idea, though I am not an iota familiar with > compiler/garbage collector internals. Can we have some sort of > internally maintained priority associated with allocated objects? > The garbage collector should look at these objects first when it > tries to free anything. The objects which hold other system > resources apart from memory, such as file handles, video memory, and > so on could be allocated as higher priority objects. Is such a thing possible? > > 2008/4/16 Conal Elliott <[EMAIL PROTECTED]>: > 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 > > -- Best regards, Bulat mailto:[EMAIL PROTECTED] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe