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.<br>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.<br>
<br>Regards,<br>Abhay<br><br><div class="gmail_quote">On Wed, Apr 16, 2008 at 11:55 AM, Bulat Ziganshin &lt;<a href="mailto:bulat.ziganshin@gmail.com">bulat.ziganshin@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Abhay,<br>
<br>
Wednesday, April 16, 2008, 9:30:34 AM, you wrote:<br>
<br>
i think it will not work with current ghc GC - it scans entire<br>
memory/nursery when garbage collected so anyway you will need to wait<br>
until next GC event occurs<br>
<div><div></div><div class="Wj3C7c"><br>
&gt; Your mail gives me an idea, though I am not an iota familiar with<br>
&gt; compiler/garbage collector internals. Can we have some sort of<br>
&gt; internally maintained priority associated with allocated objects?<br>
&gt; The garbage collector should look at these objects first when it<br>
&gt; tries to free anything. The objects which hold other system<br>
&gt; resources apart from memory, such as file handles, video memory, and<br>
&gt; so on could be allocated as higher priority objects. Is such a thing possible?<br>
&gt;<br>
&gt; 2008/4/16 Conal Elliott &lt;<a href="mailto:conal@conal.net">conal@conal.net</a>&gt;:<br>
&gt; &nbsp;Are Haskell folks satisfied with the practical necessity of<br>
&gt; imperatively &amp; explicitly reclaiming resources such as file handles,<br>
&gt; fonts &amp; brushes, video memory chunks, etc?&nbsp; Doesn&#39;t explicit freeing<br>
&gt; of these resources have the same modularity and correctness problems<br>
&gt; as explicit freeing of system memory (C/C++ programming)?<br>
&gt;<br>
&gt; I wrote a lovely purely functional graphics library that used video<br>
&gt; memory to lazily compute and cache infinite-resolution images, and I<br>
&gt; found that I don&#39;t know how to get my finalizers to run anytime soon<br>
&gt; after video memory chunks become inaccessible.&nbsp; Explicit freeing<br>
&gt; isn&#39;t an option, since the interface is functional, not imperative (IO).<br>
&gt;<br>
&gt; I guess I&#39;m wondering a few things:<br>
<br>
&gt; * Are Haskell programmers generally content with imperative and<br>
&gt; bug-friendly interfaces involving explicit freeing/closing of resources?<br>
&gt; * Do people assume that these resources (or handling them frugally)<br>
&gt; aren&#39;t useful in purely functional interfaces?<br>
&gt; &nbsp;* Are there fundamental reasons why GC algorithms cannot usefully<br>
&gt; apply to resources like video memory, file descriptors, etc?<br>
&gt; * Are there resource management techniques that have the<br>
&gt; flexibility, efficiency, and accuracy of GC that I could be using for these other resources?<br>
&gt;<br>
&gt; Thanks,<br>
&gt; &nbsp; - Conal<br>
<br>
&gt; 2008/4/14 Abhay Parvate &lt;<a href="mailto:abhay.parvate@gmail.com">abhay.parvate@gmail.com</a>&gt;:<br>
&gt; &nbsp;Hello,<br>
<br>
&gt; In describing the Handle type, the GHC documentation says (in the System.IO documentation):<br>
<br>
&gt; GHC note: a Handle will be automatically closed when the garbage<br>
&gt; collector detects that it has become unreferenced by the program.<br>
&gt; However, relying on this behaviour is not generally recommended:<br>
&gt; the garbage collector is unpredictable. &nbsp;If possible, use explicit<br>
&gt; an explicit hClose to close Handles when they are no longer<br>
&gt; required. &nbsp;GHC does not currently attempt to free up file<br>
&gt; descriptors when they have run out, it is your responsibility to &nbsp;ensure that this doesn&#39;t happen.<br>
<br>
&gt; But one cannot call hClose on Handles on which something like<br>
&gt; hGetContents has been called; it just terminates the character list<br>
&gt; at the point till which it has already read. Further the manual says<br>
&gt; that hGetContents puts the handle in the semi-closed state, and further,<br>
&gt;<br>
&gt; A semi-closed handle becomes closed:<br>
&gt; &nbsp;if hClose is applied to it; &nbsp;if an I/O error occurs when reading<br>
&gt; an item from the handle; &nbsp;or once the entire contents of the handle has been read.<br>
&gt; So do I safely assume here, according to the third point above,<br>
&gt; that it&#39;s fine if I do not call hClose explicitly as far as I am<br>
&gt; consuming all the contents returned by hGetContents?<br>
<br>
&gt; Thanks,<br>
&gt; Abhay<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; &nbsp;Haskell-Cafe mailing list<br>
&gt; &nbsp;<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt; &nbsp;<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
&gt;<br>
<br>
<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; &nbsp;Haskell-Cafe mailing list<br>
&gt; &nbsp;<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt; &nbsp;<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
&gt;<br>
<br>
<br>
&gt;<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Best regards,<br>
&nbsp;Bulat &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;mailto:<a href="mailto:Bulat.Ziganshin@gmail.com">Bulat.Ziganshin@gmail.com</a><br>
<br>
</font></blockquote></div><br>