[Haskell-cafe] Loading a texture in OpenGL

[Clark Gaebel]

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 <aspergesoepje at gmail.com> wrote:

> On Tue, Feb 7, 2012 at 5:23 AM, Austin Seipp <mad.one at 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.one at 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 <cgaebel at 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 <benl at 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 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
> >
>
> 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 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/20120207/150b7b89/attachment.htm>