Call unregister for garbage collected events made by AddHandler.

[Abastro]

I found that unregister is not called when events are GC-ed.
In fact, the unregister functionality is discarded entirely in fromAddHandler call.
Could you make it so that it calls unregister on GC, so relevant widgets and signal generators could be properly garbage-collected?

[HeinrichApfelmus]

That's a good point. 🤔 I will look into it.

[Abastro]

I have a question regarding reactimate.
Consider the code

reactimate (foo bar <$> eBaz)

Suppose there is no other references to bar. When eBaz provably becomes never, does bar get GC-ed?
If it does not, I am worried of explosion in memory footprint.
(Dynamic widgets require reactimate calls during execution, so memory would leak if the reactimate is not taken care of)

[HeinrichApfelmus]

When eBaz provably becomes never, does bar get GC-ed?

Not at the moment, unfortunately, but eliminating events that are provably never is an optimization that I want to implement in the future.

[Abastro]

I see, how about event once eBaz? Does it get GC-ed after eBaz invoked once?
EDIT: I just tested it. It seems like act is GC-ed when

eAct <- switchE (act <$ eSignal) (never <$ eFree)
reactimate eAct

but it does not when

eAct <- act <$ switchE eSignal (never <$ eFree)
reactimate eAct

So, reactimate holds the output event in direct vicinity? While connected events are discarded.

[HeinrichApfelmus]

I see, how about event once eBaz? Does it get GC-ed after eBaz invoked once?

Unfortunately, not — the optimization about never is also the optimization that would make this work for once.

So, reactimate holds the output event

Yes, reactimate ensures that the output event is reachable and not garbage collected.

[Abastro]

Can I ask why reactimate ensures that output events are not garbage-collected? I thought the event source would keep a reference to the event if it needs to emit more. Is there a reason to specifically keep the output event alive?

[HeinrichApfelmus]

Can I ask why reactimate ensures that output events are not garbage-collected? I thought the event source would keep a reference to the event if it needs to emit more. Is there a reason to specifically keep the output event alive?

That's a good question — there are two ways in which garbage collection could operate: Either the source keeps events alive or the sink keeps them alive. I felt that I had to decide for one, and picked the sink, as this plays better with dynamic event switching: We can create many events that stem from the same source, which are at some point in their life cycle connected to a sink, but then switched away from the sink forever. As these events eventually won't have any observable effect, we need to remove them. I think that the other direction can be fully captured by "optimizing never".

[Abastro]

Somehow I thought it was opposite! I guess this means each reactimate adds extra overhead. Is this correct?

[HeinrichApfelmus]

I guess this means each reactimate adds extra overhead. Is this correct?

Depends on what you mean by "overhead". The evaluation of events still proceeds by pushing from the source; so if the event does not reach a sink, it does not add overhead in the evaluation. That said, the sink does keep events alive, so that in that sense, it adds overhead.

As said, implementing "optimizing never" is on my agenda and will make it possible to remove both sources and sinks.