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

[Abhay Parvate]

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 <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080416/917d92a9/attachment.htm