[Haskell-cafe] GC'ing file handles and other resources

[Abhay Parvate]

Thanks, both for the summary and for the link. Will try to go through it.

Regards,
Abhay

On Wed, Apr 16, 2008 at 12:37 PM, Bulat Ziganshin <bulat.ziganshin at gmail.com>
wrote:

> Hello Abhay,
>
> Wednesday, April 16, 2008, 10:51:07 AM, you wrote:
>
> > 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.
>
> on the GC, all unreferenced objects are collected. there is no
> difference which ones will be collected first - anyway program is
> stopped until whole GC will be finished
>
> > 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.
>
> yes, it uses generational GC. data are first allocated in small 256k block
> and when it is filled, GC for this small block occurs. data that are
> still alive then moved to the global heap. this minor GC doesn't scan
> global heap. if it will do this, each minor GC will become as slow as
> major ones
>
> "Generational garbage collection for Haskell"
> http://research.microsoft.com/~simonpj/Papers/gen-gc-for-haskell.ps.gz<http://research.microsoft.com/%7Esimonpj/Papers/gen-gc-for-haskell.ps.gz>
>
> >
> > Regards,
> > Abhay
>
> > On Wed, Apr 16, 2008 at 11:55 AM, Bulat Ziganshin
> > <bulat.ziganshin at gmail.com> 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 <conal at conal.net>:
>  >>  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 <abhay.parvate at gmail.com>:
>  >>  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 at haskell.org
>  >>  http://www.haskell.org/mailman/listinfo/haskell-cafe
>  >>
> >
> >
>  >>
>  >> _______________________________________________
>  >>  Haskell-Cafe mailing list
>  >>  Haskell-Cafe at haskell.org
>  >>  http://www.haskell.org/mailman/listinfo/haskell-cafe
>  >>
> >
> >
>  >>
> >
> >
> >
> > --
> >  Best regards,
> >   Bulat                            mailto:Bulat.Ziganshin at gmail.com
> >
> >
>
> >
>
>
> --
> Best regards,
>  Bulat                            mailto:Bulat.Ziganshin at gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080416/aab4b95e/attachment.htm