[e-lang] Leak avoidance for register-and-forget reactors

[Kevin Reid]

A while ago I proposed the addition of "weak when-more-resolved  
reactors" in order to fix a memory leak where a promise which gets  
resolved to a promise which gets resolved to a promise which ...  
would accumulate resolved promises which never get shortened.

It now occurs to me that this could be handled with less specialized  
magic by, instead of introducing a separate internal weak-when-more- 
resolved protocol, using regular __whenMoreResolved but auditing/ 
stamping the reactor as a 'weak reactor', which can be amplified into  
a weak reference to the object whose garbage collection implies the  
reactor being useless. (This approval would be available to objects  
transferred between communicating vats, as the sender can already  
observe GC behavior.)

This generalization is particularly of interest because of a problem  
I noticed with reactor protocols in general:


Consider a promise which doesn't resolve soon (or ever), or an  
EverReporter which never, or infrequently, updates.

Both of these can have reactors registered (__whenMoreResolved,  
whenUpdated) but will not (yet) trigger them. Furthermore, there is  
no protocol for removing these reactors. Therefore, under certain  
circumstances there will be an unbounded accumulation of reactors.

This occurred to me today when I was working on a GUI project. It is  
natural to register reactors to update on-screen information; also  
for such displays of information to be closed (and reopened), or  
scrolled offscreen (and back on screen) in a list. In the worst  
cases, there could be a continuing accumulation of reactors on a  
single data source from what the user thinks of as a single displayed  
interface.

So, what can we do about this?


One way is the weak reactors I propose above. It should be possible  
to implement them in EverReporters as well as promises, though it  
might require the reactor list to be opaque magic (only operations  
being append/1 sendToAll/2).

I think it may be possible to allow safe definition of audited weak- 
reactors (or have a sufficiently powerful library of builtin ones)  
which would allow programs without weak-reference authority to avoid  
creating this class of leaks.


Another way would be a protocol to cancel a reactor (e.g. reporter <-  
whenUpdated(...) <- cancel()). I think this is equivalent in the case  
where the registerer can make weak references and finalization, as  
they can arrange to cancel the reactor when the target is GCed. This  
is also sufficient when the registerer knows explicitly that there is  
no longer interest. I don't see how it can be applied to  
__whenMoreResolved, however.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>