<font face="verdana,sans-serif">Sounds hairy. Is there any way to get reference counting garbage collection in Haskell?<br></font><br><div class="gmail_quote">On Tue, Feb 7, 2012 at 9:26 AM, L Corbijn <span dir="ltr"><<a href="mailto:aspergesoepje@gmail.com">aspergesoepje@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Feb 7, 2012 at 5:23 AM, Austin Seipp <<a href="mailto:mad.one@gmail.com">mad.one@gmail.com</a>> wrote:<br>
> Just to clarify, this guarantee possibly could be made, ghc just doesn't do<br>
> it now. In the past ghc never guaranteed a finalizer would ever be run.<br>
><br>
> Regardless I would be wary of trusting finalizers to clean up very scarce<br>
> resources. A malloc'd buffer is probably fine to have a finalizer for,<br>
> texture objects or file descriptors are a different matter. Predictability<br>
> matters in those cases.<br>
><br>
><br>
> Sent from my iPhone^H^H^H^H^HPortable Turing machine<br>
><br>
> On Feb 6, 2012, at 10:16 PM, Austin Seipp <<a href="mailto:mad.one@gmail.com">mad.one@gmail.com</a>> wrote:<br>
><br>
> It's a precise GC of course (conservative collection would be madness<br>
> considering how much memory Haskell programs chew through.) That still<br>
> doesn't ensure your finalizer will run during the next GC even if all the<br>
> references are gone by then.<br>
><br>
> Sent from my iPhone^H^H^H^H^HPortable Turing machine<br>
><br>
> On Feb 6, 2012, at 10:09 PM, Clark Gaebel <<a href="mailto:cgaebel@csclub.uwaterloo.ca">cgaebel@csclub.uwaterloo.ca</a>><br>
> wrote:<br>
><br>
> Is the Haskell garbage collector conservative, or precise?<br>
><br>
> If it's conservative, then this will only usually work. If it's precise, it<br>
> should always work.<br>
><br>
> On Mon, Feb 6, 2012 at 10:56 PM, Ben Lippmeier <<a href="mailto:benl@ouroborus.net">benl@ouroborus.net</a>> wrote:<br>
>><br>
>><br>
>> On 07/02/2012, at 2:50 PM, Clark Gaebel wrote:<br>
>><br>
>> > I would be running the GC manually at key points to make sure it gets<br>
>> > cleaned up. Mainly, before any scene changes when basically everything gets<br>
>> > thrown out anyways.<br>
>><br>
>><br>
>> From the docs:<br>
>><br>
>> newForeignPtr :: FinalizerPtr a -> Ptr a -> IO (ForeignPtr a)Source<br>
>> Turns a plain memory reference into a foreign pointer, and associates a<br>
>> finalizer with the reference. The finalizer will be executed after the last<br>
>> reference to the foreign object is dropped. There is no guarantee of<br>
>> promptness, however the finalizer will be executed before the program exits.<br>
>><br>
>><br>
>> "No guarantee of promptness". Even if the GC knows your pointer is<br>
>> unreachable, it might choose not to call the finaliser. I think people have<br>
>> been bitten by this before.<br>
>><br>
>> Ben.<br>
>><br>
>><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
<br>
</div></div>You have to be really careful with automatic cleanup using finalizers.<br>
Not only to the mentioned not cleaning up of resources but also to<br>
deleting it too early. What could happen is that you code doesn't<br>
explicitly use (= call a GL function with it) an object after binding<br>
it. Then it could be seen as a dead pointer and be deleted by it's<br>
finalizer. But thereby it might unbind the object from the binding<br>
point.<br>
Maybe a (more) realistic example is using only one shader program, you<br>
create it once, call usePorgram with it and never change it after<br>
that. As there is no other program to use you don't have to reactivate<br>
the program with useProgram or have to change anything about it. So in<br>
effect it's not used by Haskell anymore and the finalizer is run for<br>
it deleting the program. For a program this is not a big problem as<br>
the OpenGL spec tells you that it isn't deleted immediately so you can<br>
use it afterwards.<br>
<br>
With textures it's different, the are deleted immediately, so you may<br>
think you have a texture bound but in reality the finalizer might have<br>
run and deleted the texture for you. So watch doing the OpenGL memory<br>
management using the references in Haskell, as you might accidentally<br>
delete objects ahead of time.<br>
<br>
Lars,<br>
<br>
P.S. To make it worse, the bound objects (programs, textures, etc.)<br>
can also be queried and thereby there are non dead objects<br>
automatically, but there is no Haskell reference to them so the GC<br>
cannot now this.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br>
</div></div></blockquote></div><br>