isDetached

[titto]

Hi,

in the oopsla paper there is a reference to the existence of an
isDetached method for streams but I cannot see in the git code.

Also, is the isDetached property the correct approach to allow for
release of stream resources?

If we have a streams that get detached and then no more events are
passed through it there is no way of detecting that it has been
detached and therefore to free the associated resources.

Why not adding to receiverE as an optional parameter a finaliser
function to be automatically invoked by flapjax when the stream is
detached?

Regards,

titto

[Arjun Guha]

> in the oopsla paper there is a reference to the existence of an
> isDetached method for streams but I cannot see in the git code.

In the implementation, it's not a method but a field (.weaklyHeld). A
field suffices for the current implementation of Flapjax.

> Also, is the isDetached property the correct approach to allow for
> release of stream resources?

>

> Why not adding to receiverE as an optional parameter a finaliser
> function to be automatically invoked by flapjax when the stream is
> detached?

It's clear that there is a problem if you don't use weaklyHeld/
isDetached. However, there may be a range of possible definitions of
"correct behavior." The paper suggests one definition: primitive
event streams detached by a switchE/switchB should stop receiving DOM
events.

There are various approaches to implementing this behavior. Ours is
the simplest hack possible.

>
> If we have a streams that get detached and then no more events are
> passed through it there is no way of detecting that it has been
> detached and therefore to free the associated resources.

I'm not sure I follow. Right now, when a stream is detached, it is
unreachable both in JavaScript and the DOM, so it gets garbage-
collected.

Arjun

[therac25]

Which oopsla paper ?
I'm interested !

[Arjun Guha]

Here you go:

http://www.cs.brown.edu/~sk/Publications/Papers/Published/mgbcgbk-flapjax/

Arjun

[titto]

On Sep 7, 5:39 pm, Arjun Guha <arjun.g...@gmail.com> wrote:

> > If we have a streams that get detached and then no more events are
> > passed through it there is no way of detecting that it has been
> > detached and therefore to free the associated resources.
>
> I'm not sure I follow.  Right now, when a stream is detached, it is  
> unreachable both in JavaScript and the DOM, so it gets garbage-
> collected.

In the example, we would like the callback to be removed as a listener
to save both processing time and the memory taken by the callback.

Now suppose that, after the stream has been detached, the event does
not fire anymore on the element (for example, it is a click event and
the user does not click on the element anymore).

In this case there is no waste of processing time but there is still a
waste of memory as the callback will never be invoked and will
therefore never have a chance to detect that the stream is detached
and to remove itself as a listener and be garbage collected.

Is this correct?


titto

[Arjun Guha]

> In this case there is no waste of processing time but there is still a
> waste of memory as the callback will never be invoked and will
> therefore never have a chance to detect that the stream is detached
> and to remove itself as a listener and be garbage collected.
>
> Is this correct?

Yes, this is correct. We're aware of this particular memory leak. A
possible solution is to have back-references between nodes so that
isDetached propagates immediately. However, that may create more
memory leaks--I'm not certain.

Arjun