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

[Abhay Parvate]

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