[Haskell-cafe] threepenny-gui: garbage collection

Tom Ellis tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk
Sat Jan 3 11:44:18 UTC 2015


On Sat, Jan 03, 2015 at 11:34:07AM +0100, Heinrich Apfelmus wrote:
> Tom Ellis wrote:
> >Suppose that each time I make a particular threepenny-gui widget, call it a
> >`Foo`, I register an event handler using `on` so that the `Foo` can change
> >its appearance based on some `Event`.
> >
> >Suppose I create, show, and hide a billion `Foo`s, each one never to be
> >shown again.  Can they be garbage collected?  Presumably there is something
> >storing the callback that was registered for the `Event` and the callback
> >refers to the `Foo`.  How then can the `Foo`s be freed?
> >
> >`Reactive.Threepenny.register` talks about an "unregister" action but says
> >"FIXME: Unregistering event handlers does not work yet.".  But how could it
> >be known anyway when to unregister?  Is there not the possibility of a space
> >leak regardless?
> 
> (Threepenny author here.)
> 
> This is a classic example of a circular reference that occurs in
> every GUI program: A widget keeps a reference to an event handler,
> which in turn keeps a reference to the widget.

Hi Heinrich, thanks for your reply.

Actually I don't think I am thinking of a circular reference problem.  The
problem I am evisaging is that the `Event` keeps a reference to the event
handler which in turn keeps a reference to the widget.  Thus it is hard to
see how the widget can be freed before the `Event`.  A quick Google shows
this indeed a common problem in GUI programming, e.g.

    http://stackoverflow.com/questions/4526829/why-and-how-to-avoid-event-handler-memory-leaks

Is my understanding correct, or is my model of how `Event`s work in
threepenny-gui wrong?

> Of course, GHC's has a well-designed garbage collector that can
> handle this, but in Threepenny, the situation is actually worse: the
> widget is managed by the JavaScript runtime, whereas the event
> handler is managed by the Haskell runtime. I don't know any garbage
> collector that can resolve cross-runtime circular dependencies.

I haven't managed to understand the issue here.  Could you say a bit more
about that?  It sounds interesting!  I don't think it's related to my
concern though, but if it is that would also be interesting.

Tom


More information about the Haskell-Cafe mailing list