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