
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-handle... 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