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

[Bulat Ziganshin]

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