I am not saying that it should claim it as soon as it is unused; all I am saying that as soon as a priority object becomes unreferenced, it should be the first choice for collecting in the next collect. Further I was under the impression (I may be wrong) that it uses a generational GC and therefore scans allocated memory incrementally; not the whole at a time. Please correct me if I am wrong.
Regards, Abhay On Wed, Apr 16, 2008 at 11:55 AM, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: > 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
